(ISC)2 opened registration for classes and exams for its Certified Secure Software Lifecycle Professional (CSSLP) certification, with the first classes beginning this month. It’s about time! Many security zealots, like me, have been emphasizing the fact that >90% of vulnerabilities are at the software layer and most exploitations take advantage of known and un-patched security holes. This is pretty much the result of insecure software production (not just coding, but bad design and testing too) yet many of the investment dollars, standards, certification, etc. continue to be spent at the network layer.
Since the university system in USA won't embrace the problem of insecure software and start teaching students how (and the importance of) writing secure code, it is incumbent upon us as an industry to bear the cost of the burden. I'm glad to see (ISC)2 publicly launch the long-awaited CSSLP program -- it is a start in the right direction.
We need to fundamentally change the state of software development and this is a step on what will be a long path to making security a part of quality software application construction. My friend and fellow curmudgeon, Mary Ann Davidson, has long called for universities to "step it up" when it comes to educating our young software engineers and soon-to-be quality professionals. She has also called for us as an industry to resist enshrining anything like a SANS Top 25 list into contractual or regulatory requirements (after all, it is just a general list of vulnerabilities) -- rather, she and I share the philosophy of addressing problems at their root cause -- and the data breach problem that plagues us worse than swine flu these days will never get solved until it is addressed at the developer desktop (read "developer" = business analyst + architect + developer + tester/QA)
Over and out... your friendly neighborhood Security Curmudgeon
Ed,
Too right! I just posted a similar comment about the various consensus security guidelines that are coming out now. We've been working too hard to get to a risk management mindset to throw it out the window now for adherence to some list.
Here's the post:
http://irec.wordpress.com/2009/05/27/coming-to-consensus/
Why is it acceptable for a software developer to ship software that has the SANS Top 25 Most Dangerous Programming Errors contained within it? Why shouldn't a customer expect these errors be removed during the development process.
The list is an enumeration and does not specify the processes that a software developer should implement to ensure that these serious defects do not get shipped to customers. Certainly a good way to do this is to engage architects, developers, and testers with best of breed tools and processes to prevent these defects from effecting customer data and transactions. The process will be different for different languages, platforms and types of software.
There are developers shipping code today that is SANS Top 25 free. Those are the developers making secure software for the threats of today's business world.
Don't listen to developers that merely state they have a good SDLC process and are using tools. Force them to demonstrate that their process is effective. I like that I can see seatbelts and bumpers on a car. I like it better that I can see a crash test report.
-Chris
Post new comment