A spell check equivalent for building security in
The original version of this post was published on SecurityWeek.
I can honestly say that spell check is the reason I now know how to spell “separate.” It only took about 20 years of patient and faithful repetition from Microsoft Word.
The concept of spell check is intriguing when considered in the context of security. There is a significant benefit to being corrected on the spot—an immediate identification of the error in your ways. Even more beneficial is being shown a suggested correction because the repetition of the process of identification and remediation is a highly effective learning tool. Spell check educates to put itself out of business.
Traditional working patterns for software security testing have been in a consistent rut for some time. Development teams wrote code until they completed the scope of a given release, and the completed application was then tested. Results were subsequently returned back to the development team for remediation.
This is when the fun really starts, because the development team has already moved onto the next development cycle. To address the findings of the test, they have to stop their current work, get their head back into the previous cycle, and begin to investigate and remediate the findings. Some testing tools have a history of returning false positives, which means the developers must first verify that each vulnerability is real and exploitable. This places a heavy burden on the development teams, who are often incented to be on time more than to be secure.
Even security training—assuming it exists, which it often does not—is monolithic. Developers are asked to step out of the development cycle and attend classes or engage with computer-based training. As millennials enter the development job force and adoption of agile development methods expands, this training method is no longer optimal. In particular, millennials like to learn in snackable segments.
Clearly a paradigm change is needed for both software security testing and training. In response, many vendors are throwing around a term that drives me nuts: move left. The idea is rooted in waterfall development graphics where moving left in the picture means you have embedded testing earlier into the process. What incites me is that for most of these vendors, all they have moved left is the “button” to launch the same testing process.
Not exactly paradigm-changing.
Drop the talk about moving left and adopt a building security in approach by leveraging technology that acts like a spell check for security. These tools live inside the development environment and check the code for bugs as it is being developed. The tools perform a lightweight static analysis of the code and identify common errors at the source such as cross-site scripting or SQL injection.
Advanced versions of these tools also provide educational material. The tools explain the nature of the bug identified to the developer and how it can be exploited. The tools also suggest fixes to the code to eliminate the bug. Some will actually make the change after confirmation from the developer. Bugs are identified, explained, and remediated on the spot.
The benefits from this approach are clear.
