On 4/12/05, der Mouse <[EMAIL PROTECTED]> wrote: > >> 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.
Sure, but that isn't the majority. At least in my experience. > 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. Again, in my experience that is not true. Programs that are labelled 'Secure' vs something that isn't. In this case, there is a single thing - Security - that has been included in one and not the other [in theory]. Also, anyone requesting software from a development company may say: "Oh, is it 'Secure'?" Again, the implication is that it is a single thing 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). Obviously a bit of discussion takes place, not just a flat-out 'No'. -- Michael
