And I couldn't disagree more with your perspective, except for your inclusion of managers in parenthesis.

Developers take direction and instruction from management, they are not autonomous entities. If management doesn't make security a priority, then only so much secure/defensive code can be written before the developer is admonished for being slow/late/etc.

While sloppy habits are one thing, it's entirely another to have management breathing down your neck, threatening to ship your job overseas, unless you get code out the door yesterday.

It's an environment that fosters insecure habits and resultant products. I'm not talking about habits like using strncpy vs strcpy, I'm talking about validation of user input, ensuring a secure architecture to begin with, and the like. The later takes far more time to impliment than is given in many environments. The former requires sufficient specifications be given upfront - otherwise you have insufficient information to correctly use a function like strncpy.

Kind Regards,
-dsp

Michael Silk wrote:
Quoting from the article:
''You can't really blame the developers,''

I couldn't disagree more with that ...

It's completely the developers fault (and managers). 'Security' isn't
something that should be thought of as an 'extra' or an 'added bonus'
in an application. Typically it's just about programming _correctly_!

The article says it's a 'communal' problem (i.e: consumers should
_ask_ for secure software!). This isn't exactly true, and not really
fair. Insecure software or secure software can exist without
consumers. They don't matter. It's all about the programmers. The
problem is they are allowed to get away with their crappy programming
habits - and that is the fault of management, not consumers, for
allowing 'security' to be thought of as something seperate from
'programming'.

Consumers can't be punished and blamed, they are just trying to get
something done - word processing, emailing, whatever. They don't need
to - nor should. really. - care about lower-level security in the
applications they buy. The programmers should just get it right, and
managers need to get a clue about what is acceptable 'programming' and
what isn't.

Just my opinion, anyway.

-- Michael
[...]




Reply via email to