Dave, On Apr 11, 2005 9:58 PM, Dave Paris <[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' (or - security problems). Sometimes they leave 'bugs' because they don't know any better, so sure, train them. [oops, I'm moving off the point again]. All I mean is that they don't need to be the architect or engineer to have their decisions impact the security of the work. > If > security is designed into the system and the programmer fails to code to > the specification, then the programmer is at fault. Security can be design into the system in many ways: maybe the manager was vauge in describing it, etc, etc. 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. For me, it's the other way round - when receiving a design or whatever. > 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. So your opinion is that most security flaws are from bad design? That's not my experience at all... What are you classifying under that? > 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. It's just as crucial to the finsihed application as implementing that method to calculate the Net Proceedes or something. The manager wouldn't allow you to not do that; what allow them to remove so-called 'Security' (in reality - just common sense of validating inputs, etc.). -- Michael
