Software supply chain attacks: secure source, builds and deploys

Software supply chain attacks go after everything your code passes through on its way to users: your repository, your dependencies, your build and your deploy. The OWASP Software Supply Chain Security Cheat Sheet makes the point that a flaw in one part, such as a vulnerable dependency or a misconfigured version control system, can put the whole chain in jeopardy. This checklist follows the sheet, one stage at a time, and ends with a review you can run in a day.

Want a second opinion on your pipeline or a vendor you depend on? Book a meeting with whitehatstoic: it tests web apps and APIs for weak spots and gives independent codebase and vendor reviews.

Software supply chain attacks: the four ways in

The sheet uses NIST's definition: a supply chain is the collection of steps that create, transform and check software artifacts. For a developer that means your editor, your own code, third-party libraries, version control, build tools, CI/CD, configuration tools and package managers. Threats it names include dependency confusion, a compromised upstream provider, stolen code signing certificates and CI/CD exploits. It groups them into four categories:

Simplified from the OWASP Software Supply Chain Security Cheat Sheet.

• Source code: exploits of the version control system, malicious or vulnerable code added to the codebase, or building from a branch nobody approved.
• Build environment: changing the artifact without touching the source, such as poisoning a build cache, taking over a privileged build account, or publishing software built from an untrusted source.
• Dependencies: most often, using a vulnerable or compromised direct or transitive dependency.
• Deployment and runtime: a compromised privileged CI/CD account, misconfiguration, or deploying a compromised binary.

Two points from the sheet set the tone. These attacks do not need a sophisticated attacker, especially against teams with weak practices. And they spread: when a large supplier is compromised, many of its customers can be hit. The sheet's answer is that each team can still take reasonable steps to defend itself, even when a supplier is compromised.

Start with access, logs and automation

Three practices cover every stage, so the sheet puts them first.

• Strong access control. A taken-over account can inject code into a dependency, change how a pipeline runs or swap an artifact. Use least privilege and separation of duties, enforce MFA, rotate credentials, and never store credentials in clear text or commit them to source control. Our workload identity federation post shows one way to remove stored cloud keys from CI.
• Logging you act on. Every system in the chain, from version control to the servers that run the app, should log sign-in attempts and configuration changes. The sheet adds that logs must be monitored and acted on, not just kept.
• Automation. Scanning, monitoring and testing at scale need tools such as SAST, DAST, dependency scanners and container image scanners. The sheet is clear these do not replace manual review.

Source code: reviews and version control

The sheet calls peer review an important, relatively low-cost control. Reviews happen before code is merged, by people who know both the technology and secure coding, and they look for honest mistakes and for code written to do harm. Write the results down. Our secure code review post has a method.

Then lock down the repository itself. Beyond access control and logging, use its own features, such as protected branches and merge policies. The sheet also counts developer machines as part of the chain: they need endpoint security software, and only trusted, well-vetted tools and plugins.

Dependencies: assess, inventory, pin

The sheet calls third-party dependencies one of the leading risks in modern applications. It gives four steps:

1. Assess before you add. Ask the OpenSSF questions it lists: is the project actively maintained, mature and a release version? Does it have enough maintainers, keep its own dependencies updated, test for security and have a documented way to report vulnerabilities?
2. Keep an inventory. Use a software bill of materials (SBOM), produced and read automatically in your CI/CD.
3. Monitor it. Check for known vulnerabilities with tools such as OWASP Dependency Check or retire.js, and sources such as the NVD or the CISA Known Exploited Vulnerabilities catalog. Our dependency updates post covers the patch routine.
4. Pin versions. Limit each dependency to a version you have checked, with a lockfile such as npm's package-lock.json.

If your app uses AI models, those are dependencies too; see our LLM supply chain post.

Builds: isolate, sign and prove provenance

Build threats change what ships without changing the source, which is why they are hard to spot. The sheet's controls:

• Inventory and harden build tools. Record every build tool, version and plugin automatically and watch their advisories. Run them on segregated networks, remove unused services and keep pipeline configuration in version control.
• Ephemeral, isolated builds. Shared, reused build environments invite cache poisoning. Build in a VM or container that is destroyed right after.
• Few build parameters. Anyone who can change a parameter can change the build. Minimize or remove the ones users control.
• Signing. Accept only signed components and check the signature before use. If you sign, harden the signing system, or it becomes the way in.
• A private artifact repository. Review artifacts before they enter, and make sure nobody can bypass it.
• Provenance. SLSA 1.0 defines it as verifiable information about where, when and how an artifact was produced. The build platform, not a developer's laptop, should generate it, and it should be hard to forge.

Deploys and runtime: scan what ships

The sheet says not to assume the final build is safe. Scan the finished binary to find exposed secrets and components that should not be there, and to check its integrity. After release, keep watching: new vulnerabilities appear in dependencies, container images, web servers and the operating system, so you need an up-to-date inventory of what runs. Our CI/CD security post covers the pipeline in more depth.

A one-day supply chain review

Here is a way to run the sheet on one product with a repository, a CI pipeline and a container deploy. The order is ours; the checks come from the sheet.

1. Morning, access and source. List who can push, merge, change pipeline settings and publish artifacts. Confirm MFA for each, protected branches on the main branch, and no credentials in the repository.
2. Late morning, dependencies. Generate an SBOM, confirm a lockfile is committed, and run a known-vulnerability scan. Pick the three dependencies you rely on most and answer the OpenSSF questions for each.
3. Afternoon, build. Check whether builds run in a fresh environment each time, which parameters users can set, and whether the pipeline config lives in version control.
4. Late afternoon, ship. Check whether you verify signatures on what you pull, and whether you scan the final image before it deploys. Note where provenance would come from.

Write each finding as one line: what you checked, what you saw, who fixes it. This is a start, not a full test.

Frequently asked questions

What is a software supply chain attack?

An attack on any step that creates, changes or checks your software before it runs: source code, dependencies, the build, or the deploy. The OWASP sheet groups them into those four categories.

Is a lockfile enough to stop supply chain attacks?

No. Pinning limits you to versions you checked, but the sheet also calls for supplier checks, vulnerability monitoring, isolated builds, signatures and scans of the final build.

What is build provenance?

SLSA 1.0 defines it as verifiable information about where, when and how an artifact was produced. The OWASP sheet says the build platform should generate it and it should be hard to forge.

Get started

Run the one-day review on one product this month. whitehatstoic tests web apps and APIs for weak spots, with a written report and a retest after fixes, and gives independent codebase and vendor reviews. Book a meeting with whitehatstoic and tell us about your product, your deadline and your biggest worry; work is scoped after a short call.