InformIT: You need an SSG

[secureCoding2dave at davearonson.com (Dave Aronson)]

Mike Boberski <mike.boberski at gmail.com> wrote:

> A toolkit example that comes to mind, to keep this email short: the
> highly-matrixed environment (and actually also the smaller environment, now
> that I think about it) where developers fly on and off projects.

I don't quite grok what you're saying here.  The syntax looks like
you're saying that matrix management is a tool or toolkit, which
doesn't make sense to me.  Your next paragraph:

> Toolkits that enforce coding standards, and that are treated like any other
> module of the application in terms of care and feeding, are the only things
> that give security a fighting chance in environments like those.

seems more like you're saying it's an environment conducive to bad
security.  Now that I can agree with, and would extend it to quality
in general.

A typical large-company matrix management environment seems very
conducive instead to an attitude of "who gives a flying fig, all I
have to do is make it work well enough to get the customer to sign
off."  A given worker is unlikely to ever work on that same project
again, so the usual "write it well so that you can read it well later"
doesn't apply, and there's little to no other reward to "write it well
to be nice to the next poor sod who has to read it".  All the more so
in the typical Beltway Bandit (DC-speak for government contractors,
especially defense) environment, where they'll probably be laid off in
a few years anyway, so they won't be pestered by colleagues with
questions,

As for the tools, again absolutely agreed, though I'd place less
emphasis on some of the pickier aspects of "coding standards" (like do
block-opening braces get their own line, and do you put a space before
the opening paren of a function call's argument list), and more on any
automagically detectable security (or other types of quality) flaws.
A couple years ago I was on a project where I was trying desperately
to get the company to buy some kind of static analyzer, so we could
use it as part of our CM process and have Subversion automagically
reject changesets that introduced flaggable flaws.  I did at least
manage to set up the makefiles so that it would warn if any module had
no unit tests, and fail to build if any unit tests failed....

On the other claw, I still don't grok what you mean by "treated like
any other module of the application".  Maybe it's just a matter of
preferred phrasing, but "like any other *aspect*" is closer to at
least my own thoughts on it.  IOW, they usually ask "does it do the
job right" (verification) and maybe "does it do the right job"
(validation), but should also ask (for security) "does it Do The Right
Thing (whatever that may be) in the face of all forseeable types of
attacks", and (for quality) "diDTRT(wtmb)itfoafto *errors*" (including
those forced by an attack!) and "is it maintainable".

-Dave

-- 
Dave Aronson - Have Pun, Will Babble | Work: davearonson.com | /\ ASCII
-------------------------------------+ Play: davearonson.net | \/ Ribbon
"Specialization is for insects."     | Life: dare2xl.com     | /\ Campaign
-Robert A. Heinlein                  | Wife: nasjleti.net    | Email<>Web