Application Security (AppSec) tools are principally concerned with finding, fixing, and preventing security vulnerabilities in applications. There are a number of such tools, but the most commonly implemented ones include:

• 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:

Source: mend.io

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:

Source: Google

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:

THREAT	TOOL
Source Code	Provenance Attestations Provides metadata for both source code (i.e., where the source code for a proprietary or open source package came from) and built artifacts (i.e., which system was used to build the package)
Build or CI/CD	Hardened Build Service Featuring ephemeral, isolated, and hermetically sealed (i.e., no access to the internet) build environments to ensure against bad actors compromising the build process Signing Service Includes signing of the provenance attestation. Signing ensures that packages were not tampered with after being built.
Dependencies	Verification Summary Attestations (VSAs) Includes a summary of the SLSA level for each dependency (as well as for each transitive dependency) that went into building the artifact, as well as the SLSA level for the final artifact created.
Deploy/ Use	Verification Service A service that verifies that packages were built as expected (i.e., verifies the attestation), and not tampered with prior to deployment.

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