There are several techniques to identify vulnerabilities in software and systems. Smart organizations keep them in their “security toolbox” and use a combination of testing tools including:
The motivation to improve security through automated tools is to shift left in the software development life cycle (SDLC) the identification and remediation of vulnerabilities as early as possible. Fixes and remediation get more complicated as the application nears release. Figure 1 shows how the cost of remediating vulnerabilities increases dramatically as the SDLC progresses.
For in-depth coverage of the economics of software security, check out The Business Value of Secure Software whitepaper. This post focuses on using static analysis security testing as part of an organization’s security practice.
SAST tools do not require a running application and therefore can be used early in the development lifecycle where remediation costs are low. At its most basic level, SAST works by analyzing source code and checking it against a set of rules. Usually associated with identifying vulnerabilities, SAST tools provide early alerts to developers regarding poor coding patterns that lead to exploits, violations of secure coding policies, or a lack of conformance with engineering standards that will lead to unstable or unreliable functionality.
There are two primary types of analysis used for identifying security issues.
In flow analysis, the tools analyze source code to understand the underlying control flow and data flow of the code.
The result is an intermediate representation, or model, of the application. The tools run rules—or checkers—against that model to identify coding errors that result in security vulnerabilities. For example, in a C or C++ application, a rule may identify string copies, then traverse the model to determine if it is ever possible for the source buffer to be larger than the destination buffer. If it is, a buffer overflow vulnerability could result.
Avoiding certain constructs in code that’s safety-critical is the basis behind modern software engineering standards like AUTOSAR C++14, MISRA C 2012, and Joint Strike Fighter (JSF). These standards prevent the possibility of misinterpreting, misunderstanding, or incorrectly implementing unreliable code.
Pattern analysis helps developers use a safer subset of the development language given the context of safety or security, prohibiting the use of code constructs that allow vulnerabilities to occur in the first place. Some rules can identify errors by checking syntax, like a spell checker in a word processor. Some modern tools can detect subtle patterns associated with poor coding construction.
Each testing methodology has strengths. Many organizations overly focus on DAST and penetration testing. But there are several advantages to using SAST over other testing techniques.
The amount of code that’s tested is a critical metric for software security. Vulnerabilities can be present in any section of the codebase, and untested portions can leave an application exposed to attacks.
SAST tools, particularly those using pattern analysis rules, can provide much higher code coverage than dynamic techniques or manual processes. They have access to the application source code and application inputs, including hidden ones that are not exposed in the user interface.
SAST tools promote efficient remediation of vulnerabilities. Static analysis security testing easily identifies the precise line of code that introduces the error. Integrations with developers’ IDE can accelerate remediating errors found by SAST tools.
Developers receive immediate feedback on their code when they use SAST tools from the IDE. The data reinforces and educates them on secure coding practices.
Developers use static analysis early in the development lifecycle, including on single files directly from their IDE. Finding errors early in the SDLC greatly reduces the cost of remediation. It prevents bugs in the first place so developers don’t have to find and fix them later.
SAST is a comprehensive testing methodology that does require some initial effort and motivation to adopt it successfully.
While teams can use SAST tools early in the SDLC, some organizations elect to delay analysis until the testing phase. Even though analyzing a more complete application allows for inter-procedural data flow analysis, “shifting left” with SAST and analyzing code directly from the IDE can identify vulnerabilities such as input validation errors. It also enables developers to make simple corrections before submitting code for builds. This helps avoid late-cycle changes for security.
SAST analysis is misunderstood. Many teams think it’s time-consuming because of its deep analysis of the entire project source code. This can lead organizations to believe SAST is incompatible with rapid development methodologies, which is unfounded. Nearly instantaneous results from static analysis security testing are available within the developer’s IDE, providing immediate feedback, and ensuring avoidance of vulnerabilities. Modern SAST tools perform incremental analysis to view results only from the code that changed between two different builds.
Traditional static analysis security testing tools often include many “informational” results and low severity issues around proper coding standards. Modern tools, like those that Parasoft offers, allow users to select which rules/checkers to use and filter results by the severity of the error, hiding those that do not warrant investigation. Many security standards from OWASP, CWE, CERT, and the like have risk models that help identify the most important vulnerabilities. Your SAST tool should use this information to help you focus on what matters most. Users can filter findings more based on other contextual information like metadata on the project, age of the code, and the developer or team responsible for the code. Tools like Parasoft provide use of this information with artificial intelligence (AI) and machine learning (ML) to help further determine the most critical issues.
Successful deployments are often developer-focused. They provide the tools and guidance developers need to build security into the software. This is important in Agile and DevOps/DevSecOps environments, where rapid feedback is critical to maintaining velocity. IDE integrations allow security testing directly from the developer’s work environment—at the file level, project level, or simply to evaluate the code that changed.
When analyzing software for security issues, one size does not fit all organizations. It’s critical that the rules/checkers are addressing the specific issues critical to that specific application. Organizations just starting testing for security may wish to limit rules to the most common security issues like cross-site scripting and SQL injection. Other organizations have specific security requirements based on regulations like PCI DSS. Look for solutions that allow controlled rule/checker configuration that fits your specific needs, not a generic configuration.
Build security into your application. It’s much more effective and efficient than trying to secure an application by bolting security on top of a finished application at the end of the SDLC. Just as you cannot test quality into an application, the same is true for security. SAST is the key to early detection and prevents security vulnerabilities by writing secure code from the start.
SAST tools enable organizations to embrace software security from the early stages of development onward and provide their software engineers with the tools and guidance they need to build secure software.
“MISRA”, “MISRA C” and the triangle logo are registered trademarks of The MISRA Consortium Limited. ©The MISRA Consortium Limited, 2021. All rights reserved.
Arthur has been involved in software security and test automation at Parasoft for over 25 years, helping research new methods and techniques (including 5 patents) while helping clients improve their software practices.