>> The programmer is neither the application architect nor the system >> engineer. > In some cases he is. Either way, it doesn't matter. I'm not asking > the programmer to re-design the application, I'm asking them to just > program the design 'correctly' rather than 'with bugs'
Except that sometimes the bugs are in the design rather than the code. Module A has a spec saying that checking a certain aspect of the input arguments is the caller's responsibility; module B, calling module A, is written to a spec that makes it A's responsibility to check those values. Neither programmer is at fault; each module was written correctly to spec. The real problem is that the specs are incompatible - whatever part of the design and specification process allowed the two specs for module A to get out of sync with one another is at fault. (This shouldn't happen, no, but anyone who thinks that it doesn't is dreaming.) Sometimes even the specs are identical, but are written badly, leaving enough unsaid for such mismatches to occur - the art and science of writing complete interface specs, that's another subject I could rant at some length about.... > I would question you if you suggested to me that you always assume to > _NOT_ include 'security' and only _DO_ include security if someone > asks. "Security" is not a single thing that is included or omitted. Another common source of security problems is that a module (call it A) is implemented in a way that is secure against the threat model then in effect (often this threat model is unspecified, and maybe even A's coder was careful and went and asked and was told "no, we don't care about that"). This module is then picked up and re-used (hey, re-use is good, right?) in an environment where the threat model is drastically different -> instant problem. Security was included, yet security failed, and the fault does not lie with the original coder. (It lies with whoever reused the module in an environment it was not designed for.) >> It's also much more likely that the "foreman" (aka programming >> manager) told the builder (programmer) to take shortcuts to meet >> time and budget - > Maybe, but the programmer should not allow 'security' to be one of > these short-cuts. "The programmer" quite likely doesn't have that choice. Refusing to do what your manager tells you is often grounds for summary firing, with the work being reassigned to someone who will follow orders (and probably will be even more overloaded). It's also not always clear whether a given thing constitutes a security risk or not. A certain validation check that's omitted could lead to nothing worse than, say, a one-cycle delay in recognizing a given signal in the initial design, but reused in another way that nobody knew even existed at first writing, it could cause a crash (and associated DoS) or worse. /~\ The ASCII der Mouse \ / Ribbon Campaign X Against HTML [EMAIL PROTECTED] / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B