- Static Application Security Testing (SAST)
- Used to examine source code for flaws or weaknesses that could be exploited.
- Dynamic Application Security Testing (DAST)
- Used to examine a running application in order to detect conditions that could be exploited, such as may occur if the application is running with a security vulnerability.
- Interactive Application Security Testing (IAST)
- Uses a combination of static and dynamic analysis techniques in order to discover vulnerabilities in code, and ascertain whether those vulnerabilities are actually exploitable in the running application.
- Software Composition Analysis (SCA)
- Used to identify open source software modules included in the application, and list any known vulnerabilities associated with those modules.
While vulnerabilities are a significant part of securing any software supply chain, they represent just the tip of the iceberg. Like the tip, they sit in plain view to anyone paying attention to Common Vulnerabilities and Exposures (CVE) reporting, but more concerning, they eat up time and resources preventing organizations from dealing more thoroughly with the software supply chain’s underlying threats:
The problem of optics extends to the apparent growth in vulnerabilities over the past decade:
In many ways, the growth in discovered vulnerabilities is a function of its growing popularity. Back in 2009, adoption of open source was limited, with many security-conscious organizations still on the fence. Today, it’s difficult to find a single organization (non-profit, commercial or governmental) that does not make use of open source. Add to that the fact that open source code now comprises >80% of all application code (on average) and it’s no wonder we’ve found an ever-escalating number of vulnerabilities over time.
That’s not to say that vulnerabilities aren’t a real problem – they are – and we still need traditional AppSec tools to deal with them. But they only cover a very small spectrum of an exponentially growing problem. For example, compare growth in vulnerabilities to growth in supply chain attacks over the last few years for which we have the data:
In other words, vulnerabilities comprise only a small portion of the growing security risk.
Software Supply Chain Tools
Just as AppSec tools have proven invaluable for dealing with different types of vulnerabilities, we need a set of Software Supply Chain tools that can help us do the same for other supply chain threats.
To help us understand what form those tools should take, let’s first examine the threat landscape:
Threats exist across the entire software development lifecycle. While each organization may have it’s own way to develop software, most dev lifecycles include at least three fundamental stages:
- Import/Source – the process of importing third-party tools, libraries, code snippets, packages, etc, as well as pulling proprietary code from local repos.
- Build – the process of compiling, building and/or packaging code, usually via an automated system that also executes tests on built artifacts.
- Deploy/Use – the process of deploying software to customers, as well as working with built artifacts in development, test and production environments.
Best practices exist at each of these stages, as documented in numerous Secure Software Development Frameworks (SSDFs). Unfortunately, these best practices have failed to stem the rising tide of supply chain attacks, as evidenced by the fact that >60% of organizations reported having suffered from one or more software supply chain attacks in 2022.
An emerging set of standards and tools are being designed specifically to address this shortcoming. Foremost among these standards is SLSA or Supply-chain Levels for Software Artifacts, which addresses a number of supply chain threats with appropriate tools:
|Source Code||Provenance Attestations
|Build or CI/CD||Hardened Build Service
|Dependencies||Verification Summary Attestations (VSAs)
|Deploy/ Use||Verification Service
While not specifically included in SLSA, Software Bill of Materials (or SBOMs) can also help here. Often a new feature of AppSec tools, SBOMs list all the software components required to build the software, along with detailed information about each component. This makes them invaluable for quickly finding vulnerabilities in deployed software.
Conclusions: Software Supply Chain Threats Require New Tools
The explosion in software supply chain attacks has not happened in a vacuum. Many of these attacks have exploited existing vulnerabilities in order to compromise software development systems. As such, AppSec tools that can help us deal with vulnerabilities will always be an essential part of the software supply chain threat toolbox.
But these traditional security tools were never designed to counter the risks created by new kinds of software supply chain attacks. For these emerging vectors, new tools and methodologies are required.
The ActiveState Platform is just one such tool, offering a cloud-based service that provides organizations with:
- SLSA Build Level 3-compliant secure build service that automatically builds open source dependencies from vetted source code, and provides signed Provenance Attestations and VSAs for each built artifact.
- CLI (ActiveState’s State Tool) that verifies each dependency’s attestation on install to ensure they were sourced and built according to an organization’s requirements.
Read Similar Stories
The SLSA 1.0 specification provides verifiable controls and best practices to help you secure your software supply chain. Learn how.
SBOMs won’t secure your software supply chain because they lack attestation info about how components were sourced and built. Learn more.