Why Generation 1 Security Tools do not Work Today
The truth is that there is no lack of security tools in the market, the list of the static code analysis tools on Wikipedia contains several dozens of tools. However, according to a survey done by GitLab in 2019, 70% of developers don’t believe that they have the tools they need to build secure software.
How is it possible that there are a lot of security tools that exist in the market but developers don’t find them helpful in securing their code? There are four factors that lead to this paradox.
The existing tools were created mostly between 2002 and 2010, the main user for security tools at this time was the security engineer, primarily in a central security team in an enterprise. The success of these tools with the user profile of a security engineer in an enterprise setting does not mean that these tools would also work for a developer working in an agile development team.
The false positives
Classic static code analysis tools are known for false positives. While it is an annoyance, it is not a deal breaker for the security engineer. For developers, it is pretty much a deal breaker. The security engineer’s job is to do security work. They would rather over analyze than under analyze to prevent security issues from making it to production and they are usually the last line of defense for the application before going to production. For the developers, their job is not to do security work but to write new code, they are the first line of defense and definitely not the last, so too many false positives would prevent them from doing their primary task – writing new code.
Check out our article Reducing the Risk: A Software Engineering Problem, to read more on this.
Since these tools were created primarily for central security teams, integration into the software development tools and processes was not a priority. A lot of these tools added some integration into development tools after the fact, such as offering IDE plugins. These plugins are not really tightly integrated into development workflows but rather a bridge to pull developers from the development world back into the security world, something that developers are not really interested in doing.
The security team’s goal is to find as many vulnerabilities as possible in a particular application, in addition to code coverage; how many applications and how much of each application were audited by the team before going to production. Development team’s goals and KPIs are different, development team’s are mostly measured by how many features are pushed to production, and how fast these features are pushed to production. As far as vulnerabilities, how many were found and fixed and fast are these vulnerabilities fixed. Generation 1 tools were designed to help security engineers reach their goals but not necessarily for developers to reach their goals.