On Apr 7, 2005 12:43 PM, Blue Boar <[EMAIL PROTECTED]> wrote: > Michael Silk wrote: > > See, you are considering 'security' as something extra again. This is > > not right. > > It is extra. It's extra time and effort. And extra testing. And extra > backtracking and schedule slipping when you realize you blew something. > All before it hits beta.
All of this is part of _programming_ though. To me it should be on the same level as, say, using an 'Array' at an appropriate point in a program. You won't say to management: "Oh, I didn't use an array there because you didn't ask me to.". It's ridiculous to even consider. And so it should be with so-called 'Security' that is added to applications. Consider the bridge example brought up earlier. If your bridge builder finished the job but said: "ohh, the bridge isn't secure though. If someone tries to push it at a certain angle, it will fall". You would be panic stricken. Fear would overcome you, and you might either run for the hills, or attempt to strangle the builder... either way, you have a right to be incredibly upset by the lack of 'security' in your bridge. You WONT (as is the case now) sit back and go: "Oh well, fair enough. I didn't ask you to implement that, I just said 'build a bridge'. Next time i'll ask. Or make sure the public specifically requests resistence to that angle of pushing". Hopefully my point is obvious... -- Michael > Any solution that ends up with us having "secure" software will > neccessarily need to address this step as well as all others. The > "right" answer just might end up being "suck it up, and take the > resource hit." It might be "switch to the language that lends itself to > you coding securly at 75% the productivity rate of sloppy coding." I > don't know enough about the languages involved to participate in that > debate. > > Strangely enough, for the last year and a half or so, I've been sitting > here being QA at a security product company. Doing software right takes > extra resources. I are one. > > Ryan >
