Managing risk in the software supply chain

Modern software teams leverage increasingly large volumes of third-party software components in order to ship products quickly. Unfortunately, this convenience comes at a cost. As third-party complexity grows, it becomes harder for organizations to manage components, track risk, and understand their potential vulnerabilities to modern cyberattacks.

The software supply chain (SSC) comprises the entire ecosystem of people, processes, components, and tools required to source, build, package, distribute, and run software. It includes third-party source code, APIs, build systems, CI/CD pipelines, artifact repositories, and the runtime environment. Weaknesses in any link can affect everything downstream. Each new component may introduce bugs or inconsistencies between components, increasing the attack surface.

Security isn’t just a concern for software engineers. Software security vulnerabilities have serious business impacts; they can negatively affect brand trust, revenue, sales, fundraising, and even result in legal and compliance issues. Although security in third-party components can feel intimidating to maintain, it is necessary for modern software enterprises to maintain brand integrity.

Why the software supply chain is a major risk factor

The software development lifecycle (SDLC) process is filled with application security risks. Any time teams incorporate components they did not build, cannot easily audit, and rarely rebuild themselves, it negatively impacts an organization's security posture and presents a prime target for software supply chain attacks.

A weakness in any link, end-to-end, can compromise software supply chain security. Whenever a single widely used component or distribution channel is compromised, it impacts anything downstream, negatively affecting many projects and organizations at once.

Active attacks directly intrude on the supply chain. For instance, an active attack might replace a secure library with a compromised one. When the compromised library is included in new or updated software, the entire application is compromised.

Passive attacks gather information, such as monitoring how often a library is used. Attackers use this information to plan future exploits.

Common supply chain weaknesses include:

• Build and CI infrastructure. Common vulnerabilities include credentials that are too permissive, secrets that are too long-lived, and poorly isolated build systems that are vulnerable to attackers who seek to tamper with artifacts or steal sensitive information.

• Compromised update and release processes. Trusted channels can be manipulated by bad actors to introduce malicious code into packages during build, signing, or distribution.

• Malicious and lookalike packages. Many recent high-profile cyberattacks have successfully compromised public package registries. Attackers can target the package ecosystem by offering packages with similar names to trusted packages, or by including dependencies that appear legitimate but have been compromised.

• Known vulnerabilities and new threats. Both existing known CVEs (common vulnerabilities and exposures), and new zero-day CVEs can infiltrate unverified supply chains.

• Unverified ML images. It’s particularly challenging to tackle the maturity gap between development speed and security in the ML pipeline.

Standards and best practices for software supply chain management

Many best practices for reducing software supply chain risk are based on standardization, automation, and repeatability. Third-party code is essential and unavoidable in modern software product development, but you can reduce risk by thinking about security upfront and using high-quality, trustworthy components. A well-vetted SBOM (software bill of materials) reduces vulnerabilities, improves software supply chain security and auditability, makes dependencies easier to manage, and supports end-to-end automation.

Some well-known sets of standards for protecting against malware and malicious code:

• SLSA (Salsa): A security specification to improve integrity, prevent tampering, and secure packages and infrastructure.

• NIST SP 800-161: Federal guidelines for cybersecurity risk management in SSCs.

• S2C2F: Microsoft’s framework for secure consumption of open-source software, developed in partnership with the OpenSSF.

Such approaches are most effective when paired with a secure foundation of trusted, pre-verified components. Some characteristics of trustworthy components:

• Signed artifacts

• Verifiable provenance

• Continuous rebuilds

• Visible, malware-resistant consumption of dependencies

During March 2026 alone, Chainguard’s independent build pipeline successfully protected customers from major security incidents affecting packages with hundreds of millions of downloads, such as the Trivy supply chain attack, the litellm breach, the axios npm attack, and the telnyx PyPI compromise. Because our images and packages are all built from verified source code without running risky post-install scripts or consuming upstream artifacts from public registries, they protect our customers from many types of attacks on open-source components. 

Ways to improve security in the build & release pipelines

Pre-verified packages automatically protect you from many major incidents and costly surprises, but it’s also important to secure the entire developer process. End-to-end supply chain security is a continuous lifecycle responsibility that spans a complex ecosystem of source, build, distribution, and runtime tools & management processes. We advocate for a secure-by-default DevOps approach where automated security scans run at every stage to catch issues as early as possible, minimize complex failures, and empower developers to move faster.

Some DevOps security tips:

• At the CI stage: Scan for vulnerabilities. Use SAST (Static Analysis) to identify insecure auth logic and prevent hard-coded secrets from entering version control. Use SCA (Software Composition Analysis) to identify vulnerable dependencies. Configure automated failsafes so that builds will fail if a high-risk vulnerability is detected.

• At the deployment stage: Use DAST (Dynamic Analysis) to catch runtime vulnerabilities in staging and production environments.

• Avoid single points of failure: Restrict access to build and release systems so that no single account has complete end-to-end permissions to modify source code, build artifacts, and release pipelines.

Chainguard Actions helps teams automate CI/CD by providing a secure catalog of verified CI/CD workflows, speeding up development without compromising on security.

Risk management for third-party container images

General-purpose container images are more versatile but more complex to test and maintain, increasing their attack surface and making them more vulnerable to malware. The time and morale burden of dealing with CVEs is immense, as detailed in our report, The True Cost of CVE Management in Containers. It’s a huge challenge for software teams to keep up with all known CVEs, let alone vet every dependency for new CVEs. 

That’s why we do that work for you. Chainguard Containers is the industry’s largest zero-CVE container image catalog. Our minimal, distroless images provide malware-resistant dependency consumption, support transitive dependency visibility, and are continuously rebuilt from source with verifiable provenance. This reduces potential attack surface and eliminates manual image maintenance, helping teams achieve security and compliance more easily.

Start building safer and faster today

Chainguard is built to integrate cleanly into your existing environment and deliver security at scale. Ready to see how we can help your organization? Get in touch with the Chainguard team to learn more.