In fact, many of these concerns have been discussed since as early as the 1960s and 1970s, when military and aerospace software and applications needed to be thoroughly vetted for vulnerabilities that foreign adversaries might have sought to exploit. While application security testing has come a long way since then and security has become more closely integrated within the software development life cycle, underlying concerns persist.
In order to address these concerns, development teams are required to put their software through a series of rigorous security tests to determine the susceptibility to common attacks and then implement fixes or mitigating controls to prevent such attacks prior to the release of the application to a broader user base.
Static application security testing
One of the first forms of testing that developers used was vetting source code via the use of static application security testing (SAST) tools. These tools evaluate an application’s source code or executable (compiled binary) form to identify security flaws that might be present because of poor coding practices or oversights in development processes.
Lint, released in 1978, was one of the first SAST tools. After being added to the Unix operating system as a utility the following year, Lint served as the one of the leading solutions for decades. Currently, hundreds of different commercial and open-source solutions can be used for a wide variety of languages and use cases. (The Open Web Application Security Project (OWASP) Foundation has compiled a list of some of these solutions.) SAST tools are considered a form of open-box security testing, meaning that the focus of the tests is on the design and structure of the software rather than the function of the software. For this reason, open-box testing typically is facilitated by individuals with deep familiarity of the software, such as software developers.
SAST tools are beneficial because they can be integrated into early phases of the development process, they do not require a fully functioning application, and they can work with many programming languages (though a language-specific tool might yield better quality results). Additionally, SAST tools usually can be embedded into the integrated development environment to facilitate continual testing and near real-time feedback that can be used to educate developers on secure coding practices. SAST tools also can effectively identify vulnerabilities, such as input validation, integer overflows or numerical errors, race conditions, improper pointers and references, and others that can be addressed early in the development life cycle.
However, SAST has shortcomings that should be taken into consideration. First, SAST tools tend to identify a large number of false positives and trivial issues that do not present a significant risk by themselves. Often, the large number of false positives and misclassification of risks is due to the SAST tools’ lack of contextual knowledge and broad assumptions that are necessary to support a wide variety of development languages.
Unfortunately, this high false-positive rate and large number of insignificant and reported vulnerabilities can desensitize developers or add the additional burden of weeding out false positives by understaffed and overwhelmed development teams. Additionally, many SAST tools do not have the functionality to check open-source components, such as referenced open-source libraries, for vulnerabilities.
Software composition analysis
Fortunately, software composition analysis (SCA) tools can be used to help identify vulnerabilities in open-source components. According to the 2021 Open Source Security and Risk Analysis Report (OSSRA) by Synopsys, open-source components are becoming increasingly prevalent in codebases. A common misconception is that open-source components do not contain any vulnerabilities, when the reality is simply that open-source components allow for more transparency so that members of the information security community can vet those components for vulnerabilities.
But of course, vulnerabilities can still persist, despite an increased number of eyes on the software. For example, the OSSRA notes that 98% of codebases audited in 2020 contained some open-source components and that 84% of those codebases had at least one public open-source vulnerability, with an average of 158 vulnerabilities per codebase.
While these vulnerabilities tended to be classified as medium risk, organizations still should be aware of them and implement appropriate mitigation techniques. SCA tools can provide real value in pinpointing and resolving issues. These tools can scan the application codebase in order to identify open-source components and any associated known vulnerabilities, and they can suggest fixes that can be applied. (OWASP has a listing of open-source and commercial SCA tools.)
Dynamic application security testing
While SCA and SAST tools effectively identify vulnerabilities that might exist based on the source code alone, they often are incapable of identifying critical vulnerabilities that would be identifiable only while an application is running. Enter dynamic application security testing (DAST) tools.
DAST tools perform closed-box security testing, meaning that the tools do not have access to the source code and must perform outside-in checks via the application’s front end in order to determine whether or not vulnerabilities exist. This form of testing is particularly useful for identifying vulnerabilities such as cross-site scripting, cross-site request forgery, structured query language injection attacks, insecure server configurations, and authentication issues.
These tools can detect vulnerabilities that would be used by malicious users in their attacks against an application. Additionally, due to the nature of the testing, DAST results tend to have lower false-positive rates when compared to SAST tools, and the vulnerabilities can be higher risk in nature. The DAST tools follow a similar methodology to an application penetration test by enumerating the application pages and functionality, probing the enumerated areas for vulnerabilities, attempting to exploit the identified vulnerabilities to weed out false positives, and then classifying the vulnerabilities in a report based on the success of the exploitation attempts.
However, DAST tools do have some limitations. They typically operate with a predefined series of vulnerabilities to check for, and – in order to avoid any operational disruptions – they often do not attempt to actually execute payloads. For this reason, DAST tools that do actually execute payloads should be used to scan applications that are hosted in production-adjacent or mirrored nonproduction environments, such as a development or test environment, in order to simulate production-level controls without the risk of affecting production data. (OWASP has a listing of open-source and commercial DAST tools.)
The right application security testing method for your organization
When it comes to application security testing and information security more generally, no silver bullet can address every risk or identify every vulnerability. Ideally, developers will have a security-by-design mindset in a development-security-operations-focused environment. But even then, vulnerabilities can persist.
Therefore, using a variety of testing and prevention tools in conjunction with one another can help developers address security concerns holistically. Developers should use DAST tools to supplement SAST and SCA tools so that coding errors, dynamic run-time issues, and configuration vulnerabilities can be efficiently identified and remediated in the development life cycle.
When combining these automated testing tools with hands-on penetration testing by a trusted partner, organizations can better perform their due diligence in protecting applications and, subsequently, users’ information.
