Software Supply Chain Security: Risks and Best Practices

What Is Software Supply Chain Security?

A software supply chain is everything involved in getting software from a developer to a user's device: source code repositories, open-source dependencies, build pipelines, code signing and the channels that deliver releases and updates. If attackers compromise any of these stages, they don't need to break into your application. Your own systems build, sign and ship their code, and it reaches users looking like a normal release.

That's the difference from application security. Application security looks for flaws in running software, such as injection bugs or broken authentication. Supply chain security asks an earlier question: was the software changed by someone else before it reached the user?

Where Supply Chain Attacks Happen

Open-Source Dependencies

A typical project pulls in hundreds of packages, most of them indirectly through other packages. Attackers publish malicious packages to public registries, sometimes under the same name as a company's internal package but with a higher version number, so the build system picks the public copy. Researcher Alex Birsan demonstrated this trick, known as dependency confusion, against dozens of large companies in 2021.

Vulnerabilities hidden deep in the dependency tree are just as dangerous. When Log4Shell (CVE-2021-44228) was disclosed, many organizations needed days just to find out whether the Log4j library was in their software. In the XZ Utils case (CVE-2024-3094), an attacker spent about two years earning maintainer trust before hiding a backdoor in the project, and it was discovered by chance in 2024.

Repositories and Build Pipelines

Repositories and CI/CD pipelines have access to source code, secrets and often the signing process itself. A compromised developer account, a leaked access token or a hijacked build server lets attackers change code before it's compiled or collect credentials from environment variables and logs. In the SolarWinds attack, discovered in 2020, attackers got into the vendor's build environment and added a backdoor to Orion updates. The updates were signed as usual, and thousands of customers installed them.

Code Signing and Distribution

A valid signature tells users and operating systems that software comes from a known publisher and hasn't changed since it was signed. If an attacker steals the signing key, they can sign malware that passes the same checks as your real releases. Unsigned releases, intercepted downloads and replaced update packages are risky too, and update channels are especially attractive because users rarely question an update.

Software Supply Chain Security Best Practices

Sign Every Release

Sign every executable, installer, script and package you ship, not only the main application. Add a timestamp when signing so the signature stays valid after the certificate expires, and verify signatures as part of the release process so that an unsigned or wrongly signed file never goes out. For containers and open-source packages, Sigstore and its cosign tool are a common way to sign and verify artifacts.

Store Signing Keys in Certified Hardware

Since June 2023, industry rules require private keys for code signing certificates to be generated and stored on hardware certified to FIPS 140-2 Level 2, Common Criteria EAL 4+ or an equivalent standard. A key can no longer sit in a PFX file on a developer's machine. There are three ways to meet this requirement:

• Hardware token. A USB device such as a YubiKey FIPS or SafeNet token. It suits individual developers and small teams signing on one machine.
• On-premises HSM. A network-attached hardware security module in your own infrastructure, for organizations that sign in volume and want full control over their keys.
• Cloud HSM. A certified HSM service from a cloud provider, which fits well into automated CI/CD pipelines.

Whichever option you choose, limit who and what can use the key, and keep an audit log of every signing operation. If you suspect a key has been exposed, revoke the certificate and get a new one immediately.

Know and Control Your Dependencies

Keep a Software Bill of Materials (SBOM), a list of every component in your software with its version and origin. When the next Log4Shell appears, an SBOM tells you in minutes whether you're affected. Tools such as Syft can generate one in CycloneDX or SPDX format on every build. On top of that:

• Scan dependencies in the CI pipeline with a software composition analysis (SCA) tool such as Grype, Trivy or Dependabot.
• Pin exact versions and verify package hashes instead of pulling the latest release.
• Use an internal mirror or a vetted registry, and make sure internal package names can't be resolved from public registries.
• Check a project's security health with OpenSSF Scorecard before adding it.

Lock Down the Build Pipeline

Give build systems only the access they need: scope secrets to the jobs that use them, use short-lived tokens instead of long-lived credentials and keep signing separate from other steps. Protect repositories with multi-factor authentication and mandatory reviews on protected branches, and encrypt every connection between repositories, build servers, artifact storage and deployment targets with TLS, internal ones included.

To measure progress, the SLSA framework (Supply-chain Levels for Software Artifacts) defines build levels from 0 to 3 based on how well your builds resist tampering and how reliably you can prove where an artifact came from.