Your proposition was that developers will always make mistakes and introduce stupid problems, so a QA team/process is necessary. While I agree that there should be a QA/'audit' at some point, it shouldnt be the stage that is relied on. Applications that are flawed from the design stage onwards will become expenditure blackholes, especially after going through any QA process which should highlight these.
Potentially yes, but most of the larger companies appear to already do this. A quick search through google shows that Oracle atleast already have, and/or are actively hiring security engineers involved with Java (for example). Flaws will always pop up and I think we may now be bordering on discussing what counts as negligence in some cases. Your 5-chained-0day-to-code-exec, in my opinion, does not count as negligence and comes from the developer effectively not being a security engineer, but doing the job of a developer. In my opinion we are not at the stage in industry where we can consider/expect any developer to think through each implication of each feature they implement, without a strong security background as much as we may appreciate it. Negligence in my opinion of security vulnerabilities is having obvious format string bugs/buffer overflows when handling user input for example, or incorrect permissions, or just a lack of consideration to obvious problems. Developer training should pick up on the obvious bugs, or atleast give developers an understanding of how to handle users/user input in a safe manner, and know the implications of not doing so. On Sat, Apr 20, 2013 at 11:58 PM, Bryan <br...@unhwildhats.com> wrote: > I think the definition of 'needless staff' highly depends on whether you > want 'vulnerable software'. > > Educating current developers is absolutely a good idea, but still not > foolproof. The bottom line is that if you want safe software, you need > to invest in proper development. As far as I am concerned, for large > companies like Adobe and Oracle, where software bugs in your product > have a direct impact on the safety of your customers, that involves > hiring specialized staff. > > On Sat, Apr 20, 2013 at 11:49:22PM +0100, Benji wrote: > > (in my opinion) > > > > On Sat, Apr 20, 2013 at 11:42 PM, Benji <m...@b3nji.com> wrote: > > > > Yes, a better idea would be to educate and inform developers. At a > > business level atleast this will a) save extra expenditure on > needless > > staff and extra departments b) result in faster turn arounds as > there's > > then less time needed for remediation. At a technical level, it will > > atleast result in less 'dumb' bugs (assuming training and education > is > > effective and relevant). > > I think at this point expecting software to have 0 flaws or being > under > > the illusion that software will ever be flawless in it's current > state > > is like wishing really hard before bed every night that genetics and > > evolution will make you a unicorn. > > > > On Sat, Apr 20, 2013 at 11:35 PM, Bryan <br...@unhwildhats.com> > wrote: > > > > I am just saying that developers and designers make mistakes and > > that there is no getting around that. Rather than relying on the > > benevolent 0day researchers from the sky publicly disclosing their > > vulnerabilities, more responsible QA testing within the company > will > > prevent many of these vulnerabilities from occurring in the first > > place. Or do you have a better idea? >
_______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/