Software Security Training for Developers

[SMigues at cigital.com (Sammy Migues)]

Hi Hollis,

Thanks for the questions. I think this is the kind of information you're looking for and I've tried to keep my answers 
very non-salesy.

> - What languages/OS/environments are you developing in?

Well, we're a consultancy, so we develop in whatever language the client desires. (:-)

As for our defensive programming courses, we focused on JavaEE, core Java, .NET, and C/C++. We have had recent requests 
for COBOL, but not for PHP, Ruby, or Python, as examples.

> - Does your training address your language/OS/environment? If so, what percentage?

If I understand correctly, the answer is most training addresses it. As odd as it may seem, the general market demand 
is for good defensive programming techniques in the native language. Many customers ask for customization based on 
their threat model and specific business objectives. A smaller percentage ask for course customization for general 
technologies (e.g., encryption) and a much smaller percentage ask for customization based on the frameworks they are 
using (e.g., Spring and Acegi). On the other had, they all hate seeing examples from frameworks they don't use.

> - How long is the/each course?

We build most of our courses as 1-day modules that can be linked together (e.g., one group of lead architects and lead 
developers might get Fundamentals, then Architecture Risk Analysis, then Defensive Programming, while some QA folks 
might get Fundamentals, then Security Requirements and Abuse Cases, then Risk-Based Security Testing, and so on). A lot 
of organizations simply can't shut down development or testing for more than a day or two at a time.

> - did you go with inclass, self-paced, JIT or a combination. And which aspects to each?

All our classes are initially developed as instructor-led training. Some are then re-cast as eLearning.

> - What is your audience size? And what percentage did you train?
> - Over what period of time?

For Fundamentals classes, we can deal with larger class sizes (e.g., 30). For Defensive Programming, we try to cap at 
20 due to the nature of the labs and the time it takes to get through the questions. For Architecture Risk Analysis, a 
smaller class size is a little better because it's so interactive.

Between on-site classes, conference tutorials, some public training, and so on for analysts, architects, developers, 
and testers, we've trained thousands of individuals over the years

> - Was it mandatory? And to Sammy's point, at what management level was it loudly supported?

Well, it was being paid for, so it was always mandatory. (:-) The more interesting question may be "Did the students go 
willingly?" Whenever we had time to work with management to craft a message appropriately tuned to the intended 
audience, we've had good, willing participation. The management level we've worked with has varied from head of 
engineering up to the CIO.

--Sammy.


-----Original Message-----
From: Hollis via Rubicon Recluse [mailto:hollis at rubiconrecluse.com]
Sent: Monday, August 20, 2007 2:09 PM
To: Johan Peeters
Cc: Sammy Migues; sc-l at securecoding.org
Subject: Re: [SC-L] Software Security Training for Developers

Hi Sammie and Yo,

Tkx for the good highlevel insights. A few
questions, I'm interested specifically for
developer/designers, but I'm sure others are interested in other audiences:

- What languages/OS/environments are you developing in?
- Does your training address your
language/OS/environment? If so, what percentage?
- How long is the/each course?
- did you go with inclass, self-paced, JIT or a
combination. And which aspects to each?
- What is your audience size? And what percentage did you train?
- Over what period of time?
- Was it mandatory? And to Sammy's point, at what
management level was it loudly supported?

Thanks for your insights,
Hollis