3 reasons to upgrade your AppSec testing to tackle supply chain security

The traditional suite of tools used for application security testing (AST), static application security testing (SAST), dynamic application security testing (DAST) and software composition analysis (SCA), are mainstays of traditional software development and release 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 is used to identify vulnerabilities in open-source software and for creating a limited Software Bill of Materials (SBOM).

These software testing tools and practices, which are part of the bigger trend of shifting security left in the software development lifecycle, fail to fully address the growing range of software supply chain threats that organizations face from open-source and third-party software use in modern software development practices. While AST tools can help identify vulnerability and exposure risk in internally developed code and open-source libraries, they completely miss third-party software tampering, malware injections 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 three key focus areas from the report.

Get RL's Essential Guide: Software Supply Chain Security for Dummies

1. Open source is just one component of the supply chain security equation

SCA helps organizations identify and address vulnerabilities in open-source libraries. But it cannot identify third-party and commercial software that comprises the modern software supply chain — and the emerging risks associated with them: code tampering, malware, backdoors and other threats. 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.

Risk from third-party sources is 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.

And attacks such as SolarWinds are not the only common supply chain attack vector that current AST methods fail to address. SAST, DAST and SCA approaches cannot also not 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.

Traditional AST 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.

2. Traditional AST focuses on vulnerabilities, missing malware and more

The traditional focus of AST was on testing source code for known vulnerabilities and configuration issues. SCA goes a step further, using binary analysis, but still only looks for vulnerabilities. Software supply chain security tools shift the focus to malware, by exposing unanticipated behaviors, code tampering, certificate misconfiguration issues, secrets compromises and other risks. 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.

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.

3. SCA-based SBOMs provide only a limited view of software risk

SCA provides 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 Software Bill of Materials (SBOM), based on its ability to 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, as noted above, modern supply chain threats extend well beyond open-source software and vulnerabilities. ReversingLabs' State of Software Supply Chain Security 2022-23 describes in detail how organizations face threats from a variety of other supply chain attack vectors, including commercial third-party software and code repositories.

Software supply chain security is redefining AppSec

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 comprehensive software supply chain security solution is needed to fill the gaps in traditional application security testing.

A complete, end-to-end software supply chain security programs also needs to support workflows for the entire security organization, across software development and app sec teams, as well as third-party risk teams and Security Operations Center (SOC) teams, the report concluded.

In a new Special Report, The Evolution of Application Security, ReversingLabs explores the state of SCA tooling — in the context of Forrester's new Software Composition Analysis Landscape, Q1 2023 — and explains how software supply chain security is redefining application security.

ReversingLabs Field CISO Matt Rose notes in a recent post:

Software supply chain security needs to be recognized for what it has become: A separate discipline within the application security ecosystem.