Zaraki KenpachiI’ve been in application security for more than decade, and during that time, software development has changed. Open source has become the dominant contributor to applications, with 99% of tested applications using some open-source components, and open source code accounting for 70% of the code from tested applications. Meanwhile the number of vulnerabilities has skyrocketed to more than 17,300 in 2019, up from 5,700 a decade ago.
Yet many things have not changed. In its State of Application Security 2024 report, Forrester predicts that software vulnerabilities will continue to be the most common method for external attackers to compromise systems. And while application security is no longer boxed out of software development, the two teams—development and security—do not always get along.
The role of static application security testing (SAST) hasn’t changed, but the technology has become better at accurately detecting flaws, delivering results that developers can use, and integrating more seamlessly with agile development pipelines. DevOps teams still need to approach testing the right ways and focus on the right problems, however.
Here are four lessons I’ve learned about SAST implementations in over a decade of application security practice.
1. Angering your developers is dangerous
SAST can and should be added to the software development lifecycle in a variety of ways, but some slow down development, while others do not. Application security professionals should align their efforts with developers and prioritize the production of functional code on a quick delivery time frame. Rather than merely seeking to avoid culture clashes, the security team should actively support development.
Integrating static code analysis into the IDE, for example, is critical, because it allows the developer to catch simple errors before they become security and quality issues. Linters and simple static tools are our first chance to tell the developer that there is a problem with the code and to teach the developer to avoid such problems in the future.
2. Accurate results are king
The quality of the application security team’s results is critical. When developers start triaging hundreds of potential vulnerabilities only to find that the first handful are not issues, they lose confidence in the security team. Tuning any SAST tools to bubble up the most critical and accurate results makes triaging more efficient. The best tools also give broad, accurate coverage of a variety of issues in different languages and frameworks.
In the latest Wave report for SAST, for the first quarter of 2024, Forrester highlights vendors that scored best in the accuracy of results, mainly because of deep support for the most popular programming languages and code syntax.
3. Automation is your friend
DevOps agility relies on automation. Automating static analysis should lead to a reduction of work, not an increase. SAST tools with stock settings will often produce a lot of false positives. Having a tool that can automate triaging potential defects, and that remembers patterns that are not vulnerabilities, can dramatically reduce the number of issues that security teams and developers need to assess, the same way as having a devops dedicated service provider like this firm: https://duplocloud.com/solutions/devops-as-a-service/.
To take full advantage of automation, we often recommend that security and development teams do burn-down sprints on specific classes of vulnerabilities. For the first quarter, for example, try to eliminate all SQL injection or cross-site scripting (XSS) in your code. Not only will your team get faster at remediating these issues, but the automation will be tuned more quickly as well, and developers will learn the most secure patterns.
4. Deep analysis needs to be done the right way
The best way to incorporate SAST tools into DevOps is by integrating the most accurate tests that can be resolved quickly. However, doing so does not mean that deep analysis of the source code is not necessary. The code repository for the program should be regularly scanned to find more complex problems that the application security team should consider.
With DevOps-style software development lifecycles, code maintenance and deployment are centralized in a common repository, which makes in-depth analysis of code easier to accomplish. The security team can make sure that any results for the development team have been adequately assessed and a course of action documented.
Do SAST right and boost your dev cadence
While security has gained a seat at most development team’s tables, do not believe for one minute that the days of insecure software architectures are gone. A look at the security problems encountered by Parler prior to its shutdown underscore that poor software security is poor development.
SAST is the first line of defense against vulnerabilities in your software, and with the right tools and the right approach, it can improve your development cadence rather than hobble it.
Hugh Hay
