Back to the bridge or house example, would you allow the builder to leave off 'security' of the structure? Allow them to introduce some design flaws to get it done earlier? Hopefully not ... so why is it allowed for programming? Why can people cut out 'security' ? It's not extra! It's fundamental to 'programming' (imho anyway).
This paragraph contains the core dichotomy of this discussion.
The builder and the programmer are synonomous.
The builder is neither the architect, nor the engineer for the structure. If the architect and engineer included "security" for the structure and the builder failed to build to specification, then the builder is at fault.
The programmer is neither the application architect nor the system engineer. If the architect and engineer fail to include (or includes faulty) security "features" (as though it were an add-on, right) then the programmer is simply coding to the supplied specifications. If security is designed into the system and the programmer fails to code to the specification, then the programmer is at fault.
While there are cases that the programmer is indeed at fault (as can builders be), it is _far_ more often the case that the security flaw (or lack of security) was designed into the system by the architect and/or engineer. It's also much more likely that the "foreman" (aka programming manager) told the builder (programmer) to take shortcuts to meet time and budget - rather than the programmer taking it upon themselves to be sloppy and not follow the specifications.
In an earlier message, it was postulated that programmers are, by and large, a lazy, sloppy lot who will take shortcuts at every possible turn and therefore are the core problem vis-a-vis lousy software. It's been my expreience that while these people exist, they wash out fairly quickly and most programmers take pride in their work and are highly frustrated with management cutting their legs out from under them, nearly _forcing_ them to appear to fit into the described mold. Ever read "Dilbert"? Why do you think so many programmers can relate?
I think the easiest summary to my position would be "don't shoot the messenger" - and that's all the programmer is in the bulk of the cases.