Language agnostic secure coding guidelines/standards?

[dwheeler at ida.org (David A. Wheeler)]

Pete Werner:
> I've been tasked with developing a secure coding standard for my
> employer..... everything i've found is mostly focussed on web
> applications or language/platform specific. Does anyone know of
> something that may be what I'm looking for?

It's not exactly what you're looking for, but you can take a peek at my 
book, which is on-line:
http://www.dwheeler.com/secure-programs/

It's language agnostic, it provides guidelines for secure coding, and it 
applies to both web apps & non-web-apps.  It _does_ focus on the 
Unix/Linux platform, as it was intended to... but at this point the 
majority of it is actually platform-agnostic.

It is _NOT_ a checklist, though.  Instead of focusing on a checklist for 
humans, I would suggest using a static analysis tool to implement as 
much of a "checklist" as possible. Then any checklist you create should 
only include things that CANNOT be easily automated (e.g., "no default 
password").

However: TRAIN THE DEVELOPERS FIRST.  Use my book, another book, 
whatever, but TRAIN them.  In my experience, just handing a checklist or 
static analysis tool to developers is ineffective; a security-clueless 
developer will often not understand what the checklist/tool is saying, 
or "fix" it in a way that doesn't solve the problem.  In contrast, 
having your developers understand security will mean that even WITHOUT a 
checklist/tool, they'll produce much better software... and then 
checklists & tools can actually be helpful.  Since today's "average 
developer" has no clue about security, you MUST train them... you can't 
assume they start that way.

For a funny example where just handing someone a static analysis tool 
didn't do any good, see:
  http://www.dwheeler.com/flawfinder/#fool-with-tool
In this case, RealNetworks used a static analysis tool (flawfinder), but 
instead of fixing the vulnerabilities flawfinder found, they just 
inserted directives to tell flawfinder to stop reporting the 
vulnerabilities.  Of course, this didn't actually FIX the 
vulnerabilities...!  And my thanks to RealNetworks for coming clean 
about their mistake; I'm sure they're neither the first NOR last, and we 
can learn from them.


--- David A. Wheeler