How to prevent software supply chain attacks

A supply chain attack is a cyberattack that targets vulnerabilities in an organization’s trusted third-party vendors, software, or hardware providers, with the goal of infiltrating systems and propagating damage downstream. Instead of attacking the organization directly, attackers compromise the supply chain to gain access, steal data, or deploy malware at scale.

Supply chain attacks are not new, but in 2020, the industry started paying increased attention to them. In 2019, Russian state-linked attackers breached SolarWinds and penetrated thousands of SolarWinds’ customers via malicious code injected into the company’s network monitoring software. No one discovered the cyberattack until December 2020, and by then, more than 100 private companies and at least nine federal agencies were compromised.

The financial fallout was immense, with research showing the impact amounted to 14% of annual revenue, on average, for each affected organization in the United States.

SolarWinds wasn’t the first vector for a supply chain attack, and it won’t be the last:

• polyfill.js, a formerly safe open-source library for supporting older browsers, started injecting malware on mobile devices after a Chinese company bought the domain and GitHub account behind it.

• FortiGuard Labs discovered a zero0-day attack embedded in three PyPI packages, which, if used, would download and run a malicious binary executable.

• Even Google suffered a supply chain attack when one of its third-party vendors allowed malicious software to get pre-installed on millions of new Android devices.

Supply chain attacks can and will compromise even the most mature, security-aware organizations and their data. Software is rarely ever a discrete entity we can place in a box and call “safe.” Software is connected to other software, often with millions of dependencies, build systems, open-source packages, and third-party code components.

Unfortunately, most software vendors and guides focus on merely detecting attacks. This guide will go several steps deeper, offering a tactical, layered security approach to preventing them.

What are supply chain attacks?

Software supply chain attacks are malicious actions that exploit the systems, tools, or code companies and developers use to build and deploy software.

Digital supply chains are massively extensive and deeply intertwined, meaning an attack on one part can have a ripple effect on organizations several steps removed from the attacked component.

For example, in 2022, a developer joined the XZ Utils project and started opening PRs and fixing bugs like any good open-source contributor — until they added an exploit that would have allowed remote attackers to execute arbitrary code on vulnerable machines, meaning they nearly had access to any Linux machine running Fedora, Ubuntu, and Debian.

To do this, they built credibility over a long period, eventually earning enough trust to get permissions for the repository, including commit access and release manager rights. The developer added changes in release 5.6.0 that included a backdoor undetectable in the public Git repository and found only source code tarball releases.

The attack was only detected and eventually prevented by a Microsoft engineer, who traced a relatively minor latency issue back to the vulnerable package. Without his lucky find and detective work, this might have become a much bigger supply chain attack than SolarWinds.

Deconstructing the modern supply chain attack surface

With modern software production, there is rarely a single chokepoint or flaw. Instead, attackers probe the sprawling, fragmented ecosystem of code, tools, and people that make up supply chains.

Build-time and runtime attacks

Build-time attacks target the process of creating software, whereas runtime attacks target software that is already deployed and running.

In a build-time attack, a type of supply chain attack, adversaries compromise the development pipeline or build infrastructure, often by injecting malicious code that runs during the build or packaging stage. The SolarWinds breach is an example of a build-time attack: malware was injected into SolarWinds’ build management and CI server, TeamCity, which then allowed attackers to modify software updates delivered to SolarWinds’ customers. Other build-time attacks could target organizations through malicious dependencies, compromised CI/CD pipelines, and poisoned base images.

In a runtime attack, another type of supply chain attack, adversaries exploit vulnerabilities or weaknesses in software in production. A security researcher discovered that Log4j, an Apache software library, had a critical remote code execution (RCE) vulnerability in 2022. Any attacks exploiting this vulnerability would be runtime attacks, given that the vulnerability was already present in thousands of services, websites, and applications.

Pre-release and post-release attacks

Pre-release attacks occur during the development or building stages of the SDLC (Software Development Lifecycle). Examples include injecting malicious code into dependencies or source repositories, tampering with a build system, or changing artifacts in package registries before they’re fetched by downstream users. The XZ Utils case mentioned above is an example of a pre-release attack.

Post-release attacks occur after software is released, often by compromising distribution or update mechanisms. Attackers might hack into a vendor’s software update server to push a malicious update or intercept and replace installers on a download site.

First-party and third-party attacks

First-party components are the code and systems an organization develops and controls. A first-party attack may involve a malicious insider, negligent misconfiguration, or a compromised internal tool.

Third-party components are external components, including open-source libraries, vendor SDKs, and cloud services. A third-party attack may involve a poisoned open-source dependency, tampered containers, or a breached SaaS tool.

Direct and indirect dependency exploits

A direct dependency exploit compromises a widely used library or tool — an example might be a backdoored update of a popular npm package. An indirect exploit is similar, but instead of targeting a direct dependency, it targets sub-dependencies beneath dependencies that might otherwise seem well-vetted.

In 2018, attackers inserted malware into event-stream, a popular Node.js code library listed in npm’s warehouse of repositories. At two million weekly downloads, this library was a very rich target. This incident is considered an indirect dependency exploit because the attacker compromised a less-scrutinized sub-dependency (flatmap-stream) of event-stream, rather than event-stream itself.

Artifact-level and infrastructure-level attacks

Artifact-level attacks target software components directly, whereas infrastructure-level attacks target the systems that build, store, or deliver artifacts.

Artifact-level attacks typically involve the direct manipulation of code or a package, including backdoored binaries, poisoned base images, and malicious npm packages.

Infrastructure-level attacks typically target the platforms or tools that manage the artifacts. These attacks could include compromised CI agents, registry hijacks, and DNS-based repo spoofing.

How to prevent supply chain attacks at every layer

The software supply chain is complex, multifaceted, and granular. That’s why you can’t prevent a supply chain attack by establishing a single defense mechanism. Instead, you must harden every layer of your software supply chain, from code to containers to critical infrastructure.

Use minimal, hardened container base images

When you build containers, start with the smallest, most secure base possible. Strip out unnecessary packages and use minimal OS images to reduce your attack surface. Fewer components mean fewer potential vulnerabilities and backdoors.

Harden images by removing default credentials, disabling unused services, and consistently applying the latest patches. This includes golden images, which shouldn’t be “set-and-forget” snapshots.

If you automate rebuilds of base images (or use trusted, managed images from vendors), so that new builds always start from an updated, hardened baseline, you can stop attackers from exploiting known OS or package vulnerabilities and establishing a foothold in your software.

Lock down and verify your CI/CD pipeline

Run build jobs on ephemeral, clean instances that you destroy after use; isolated, short-lived build environments are harder for malicious actors to access. Along the same lines, ensure your CI tooling is up-to-date and hardened, including all security patches.

Monitor your pipeline proactively, because any unusual build processes or out-of-band deployments could signal a compromise. Lock down your pipelines by using separate accounts and credentials for CI tasks, use the principle of least privilege for pipeline automation, and regularly review pipeline configs.

Automate SBOM generation and verification

Every build should automatically produce a Software Bill of Materials (SBOM) that lists all the included components and dependencies. If a compromise is identified somewhere in the supply chain, an SBOM can help you react faster. For instance, organizations with SBOMs could more quickly identify systems affected by Log4j and remediate/patch those systems.

Ensure strong provenance and cryptographic signing

Provenance refers to metadata that indicates who built what, when it was built, and how. Cryptographic signing refers to signed attestations for your builds, such as “Binary X was built from Git commit Y in repository Z using build system Q at time T.”

These processes help you verify that all code and artifacts originate from a trusted source and build process, or, in the event of tampering, allow you to better distinguish between tampered and untampered code.

Patch continuously (with no developer disruption)

Maintain an up-to-date inventory of all of your third-party components and track their versions. Apply patches as soon as they emerge, because hackers will use vulnerabilities as soon as they’re discovered. Attackers exploited the Log4j vulnerability within hours.

Don’t just wait for patches, however. Vet the reputation and activity of open-source projects you depend on. Unmaintained libraries and unknown maintainers present risks. Consider alternatives or fork them.

Frameworks and standards that protect software supply chains

Modern supply chain security is guided by several key frameworks and open standards. Following established best practices spares you from starting from scratch, and allows your customers to verify your approach against a standard that demonstrates that you take defense in depth seriously.

SLSA

SLSA (Supply-chain Levels for Software Artifacts, pronounced “salsa”) is a framework that provides a checklist of controls and levels to harden your build and release processes.

As the site says, it’s “how you get from ‘safe enough’ to being as resilient as possible, at any link in the chain.” SLSA covers source control, build repeatability and isolation, provenance metadata, and trusted distribution, and maps how organizations can incrementally improve from level one to level four.

NIST 800-218 (SSDF)

NIST Secure Software Development Framework (SSDF), SP 800-218, is published by the National Institute of Standards and Technology, a federal agency referenced in many U.S. government requirements.

The SSDF includes four primary practices: Prepare the Organization (PO), Protect Software (PS), Produce Well-Secured Software (PW), and Respond to Vulnerabilities (RV). NIST is a widely respected institution, so the SSDF can be good to benchmark against, even for organizations not planning to work with government entities.

FedRAMP

FedRAMP, the Federal Risk and Authorization Management Program, is a U.S. government program for cloud service security. Under new FedRAMP guidance (sometimes called FedRAMP “High” or FedRAMP 2.0), companies must demonstrate they are managing supply chain risk for all software components.

Sigstore

Sigstore is an open-source project for code signing and verification, backed by the Linux Foundation, Chainguard, and more.

Using Sigstore or another signing solution helps strengthen your supply chain security. It makes sure that the artifacts are authentically linked to your organization and allows you to confidently require that the artifacts you use are signed by trusted parties.

OWASP SCVS

OWASP Software Component Verification Standard (SCVS) is a community-driven standard from the Open Worldwide Application Security Project with activities, controls, and best practices for handling software components securely. SCVS serves as a maturity model or checklist for software component due diligence.

Why the old approaches no longer work

We need to think of supply chain security as a moving, advancing target, not as a problem to be solved and set aside. Many teams still rely on legacy practices that may have once seemed sufficient but now create blind spots and unnecessary risks.

Examples include:

• Relying on scanners after release: Many supply chain backdoors are engineered to appear legitimate or to lie dormant, meaning that relying solely on production-time scanners means missing the window where prevention is possible.

• Using golden images that are built once and never updated: That once-secure image accumulates unpatched vulnerabilities the moment it’s created.

• Manually tracking vulnerabilities in spreadsheets or ticket queues: Hand-tracking doesn’t scale and leads to inconsistent enforcement or missed patches.

• Assuming open source is safe because it’s popular: Linus's law, "Given enough eyeballs, all bugs are shallow,” isn’t true in practice. Popular projects are often targeted specifically because of their reach, including Linux itself (see the XZ Utils backdoor).

• Ignoring the CI/CD pipeline as a security asset: Historically, security teams have focused on production servers and corporate IT systems, not build systems. A compromise in CI/CD can be more devastating than a compromised web server, however, because it can insert backdoors into all your software.

• Treating SBOMs as static deliverables: A one-time SBOM is outdated the moment a new dependency is added. An SBOM is only useful if it’s accurate and up-to-date with the software as built and used.

Ultimately, an effective supply chain security strategy must go beyond incremental improvement. To protect software development at every stage, organizations need a proactive, layered security posture built from best practices.

Future-proofing your software supply chain security

Many teams address supply chain security by creating homegrown systems for monitoring, tracking, and fixing CVEs. This is a recipe for alarm fatigue, dropped balls, and overwhelm, resulting in a lot of stress while still not comprehensively addressing the risks.

The key is to shift from a reactive stance to a proactive one with strategies to reduce future risk before it emerges.

Shift left with secure-by-default components

“Shifting left” is an ongoing security trend that, in this context, requires providing developers with secure components by default.

Curate base images and starter templates so developers use pre-hardened and regularly updated images. That way, every new service starts from a solid security baseline. Similarly, maintain an internal repository of approved libraries and versions to reduce the risk of developers pulling in something dangerous.

You can go further a tool like Chainguard for third-party application images, and fully offload management and CVE remediation (Chainguard takes ownership of the base Linux distribution, the Linux dependencies, and app dependencies as well).

Make SBOMs and provenance mandatory

Start treating SBOM generation and provenance attestation as non-negotiable parts of your release checklist. When your CI finishes a build, consider the build incomplete if it didn’t produce both.

Ditch DIY security infrastructure

DIY security tools are not a bad place to start, but they tend not to scale. A homegrown script for parsing vulnerabilities from npm outputs will likely miss edge cases, for example.

Building security infrastructure yourself is a false economy. Spend your precious engineering time building what differentiates your company, not what specialists have already built and can maintain.

Implement patch SLAs and measure CVE trends

It’s one thing to consider security a priority in the abstract and another to build SLAs for implementing patches and metrics for measuring CVE trends.

Just as security should be an automatic part of your build pipeline, establish security expectations with clear metrics and goals. You’ll be able to proactively identify shortfalls and start applying fixes that scale, reducing reactive fixes and panicked incident responses.

Why modern teams trust Chainguard to prevent supply chain attacks

According to The Linux Foundation, open source software (OSS) constitutes 70–90% of any piece of modern software. The software supply chain is big and growing bigger, and manual security efforts are proving unsustainable.

Chainguard builds and maintains a catalog of secure, lightweight versions of OSS, preventing attacks by eliminating vulnerabilities at the source. Each component is delivered with verifiable, signed, and continuous updates.

To learn more, check out our secure-by-default product suite, take the Foundations of Software Supply Chain Security course, or request a demo.