The traditional tools suite of static application security testing (SAST), dynamic application security testing (DAST) and software composition analysis (SCA) are mainstays of modern secure software development practices. SAST helps organizations detect and mitigate vulnerabilities in internally developed, pre-production source code. Many use DAST to test running applications for potential vulnerabilities and configuration errors, and SCA to identify vulnerabilities in open-source software and for creating a basic Software Bill of Materials (SBOM).
These practices have helped shift security further left in the software development lifecycle. But they fail to fully address the growing range of software supply chain threats that organizations face from open-source and third-party software use later in the development process. While AST practices can help identify vulnerability and exposure risk in internally developed code and open-source libraries, they completely overlook third-party software tampering, compromises in build platforms and other risks.
In a new report, ReversingLabs highlights where traditional AST tools fall short when it comes to addressing modern software supply chain risks. Here are four key focus areas from the report.
1. Traditional AST tools don't address how code behaves in live applications
The main focus of AST is on addressing known vulnerabilities and configuration issues in source code and running applications. It does not address how the code actually behaves in live applications. Most AST practices don't include a binary analysis of the final software package to spot unanticipated behaviors, code differences, certificate misconfiguration issues, secrets compromises and other risks that might have crept in later in the development process. The report noted:
"Traditional AST approaches rely on testing source code and open-source libraries for vulnerabilities instead of focusing on how the code behaves."
2. SAST and DAST cannot spot code tampering and other common supply chain attacks
These technologies help organizations identify and address vulnerabilities in internal software and open-source libraries during development and in production. But they cannot identify risks associated with code tampering, malware, backdoors and other malicious code introduced via the software supply chain. In the attack on SolarWinds for instance, threat actors infiltrated the company's build process, made malicious additions to approved and digitally signed code and then distributed the malware via an automated software update channel.
Such software distribution network attacks are not the only common supply chain attack vector that current AST methods fail to address. SAST, DAST and SCA approaches cannot detect risks associated with typosquatting attacks where an attacker adds malicious code to a legitimate file and tricks developers into using it by giving the modified file a name or version number very similar to the original.
Such attacks are surging. ReversingLabs’ 2022 NVD Analysis: A Call to Action on Software Supply Chain Security, showed a 289% increase in attacks on popular code repositories such as PyPI and npm over the past four years. In addition to typosquatting attacks, traditional software integrity validation tests also cannot address risks that can arise when developers bypass commit controls or when attackers leverage functional vulnerabilities in open-source code to introduce malware into an environment.
3. AST tools offer only a limited view of software risk
Automated code scanning tools are useful for spotting known, reported vulnerabilities that might creep into code because of human error. But they fare poorly when it comes to detecting malware and backdoors that an adversary might deliberately introduce into code and then go to great lengths to conceal.
AST tools also tend to focus heavily on vulnerabilities in NIST's National Vulnerability Database (NVD), a vast number of which are associated with software from a relatively small number of legacy platform vendors. Sometimes vulnerabilities in widely used platforms are not in the NVD either because the vendor did not submit the vulnerability or because the vendor is not a CVE Numbering Authority.
In either case, the known reported vulnerabilities in NVD that SAST and DAST tools use, present only part of the overall risk picture. The NVD report noted:
"Today, the NVD does not cover the full scope of development tools and platforms that are increasingly being targeted."
4. SCA is important — but only one addresses one facet of software supply chain risk
SCA deals with a binary analysis of open-source libraries in a software package. It can help identify known vulnerabilities in open-source components and help organizations build a manifest of all open-source use and dependencies in the environment. Many organizations also use SCA to address issues with software licenses and compliance.
However, modern supply chain threats extend well beyond open-source software. Organizations face threats from a variety of other supply chain attack vectors including commercial third-party software, app stores and platform-specific code repositories. Business users for instance can download a third-party productivity app, plug-in or utility app from an untrusted third-party source and end-up introducing malware into the environment.
Similarly, a vulnerable DLL file in a platform-specific code repository such as NuGet can affect connected components just as widely and significantly as a vulnerable component in open0source software. To protect against these threats, organizations require capabilities that go beyond those what traditional SCA and other AST tools provide. The report notes:
"Software supply chain security needs to be recognized for what it has become: A separate discipline within the application security ecosystem."
A call to action on modern software supply chain security tools
With supply chain attacks increasing and software packages becoming larger and more complex, organizations need capabilities that go beyond traditional AST tooling, the ReversingLab report concluded. A modern software supply chain security platform should have capabilities for addressing everything that AST tools do.
In addition, they need to enable binary analysis of final software packages, be capable of detecting threats associated with things like open-source repos, developer tooling, malware, code tampering and certificate misconfigurations. They also need to support workflows for development and app sec teams, third-party risk teams and SOC teams, the report concluded.
Learn more about the need for deeper visibility to mitigate software supply chain risk with ReversingLabs' new report, "Why Traditional Application Security Testing Alone Can't Mitigate Software Supply Chain Attacks."
Article Link: 3 reasons why you need to upgrade your application security testing to tackle supply chain security