100:10:1. The Ratio of Doom. For every 100 developers, there are 10 people in operations, and 1 person in security. It is called the Ratio of Doom because this can spell disaster for enterprises. One solution can be to automate security early and often in the development process with static analysis tools.
Justin Collins (@presidentbeef), is the Founder and CEO of Brakeman Security, a static analysis tool for Ruby on Rails applications. He presented on static analysis at the 2016 AllDayDevOps conference in a talk entitled, “Static Analysis for Security and DevOps Happiness.”
Justin started his talk noting that in DevOps developers are as responsible for stable code as the ops team is. In DevSecOps developers are as responsible for secure code as the security team is. Each has different roles, but they all have a responsibility. The security team’s role is to provide:
Tools are vital, and in DevOps tools need to be:
Of course, one set of tools are analysis tools. To help explain what they do, Justin used a compiler as an parallel to a static analysis tools, except that you get a report instead of executable code. As he said, “It isn’t magic - it is just a compiler with a different target.”
To see how static analysis tools measure up to Justin’s recommendations for DevSecOps tools, he asks, “Is it automation friendly?” If it is source code analysis, then, yes, it is. As an example, Justin provided a “Tweetable” incremental scan for Brakeman.
“Is it fast?” If you are comparing it to web scanners, then definitely yes, but many are not fast, yet. However, Justin predicts that with the momentum of DevOps, the tools are going to have to be fast. So, there will be next generation static analysis tools that will be fast and easy to automate.
“Are they consistent?” Yes. You need to have consistent results with a baseline scan and then incremental results for comparison. Static analysis tools deliver this, unlike web scanners.
“Do they provide early feedback for developers?” Security needs to shift left in the development process so that developers start thinking about security and writing it into their code.
Early security feedback in the development process is important because:
The ideal place to start source code analysis is at “Run in IDE/On Save”. Brakeman, for example, can run when the code is being saved. As Justin stated, you can really do it at any point in the process that you have code.
Many static analysis tools certainly meet the four requirements for security tools that Justin outlined. Of course, no solution is perfect, and the problem with static analysis is that every language needs it own tools, and it needs to understand the frameworks used.
There are also several types of static analysis tools:
Thankfully, Justin provides some lists to help you find an appropriate tool for you: Awesome Static Analysis and OWASP.
Justin concluded his talk with four points: Source code analysis:
Justin’s full talk, including two other examples, is available for free here. If you missed any of the other 30-minute long presentations from All Day DevOps, they are easy to find and available free-of-charge here. Finally, be sure to register you and the rest of your team for the 2017 All Day DevOps conferencehere. This year’s event will offer 96 practitioner-led sessions (no vendor pitches allowed). It’s all free, online on October 24th.