Software Supply Chain Security

The 2020s have been the decade of the supply-chain attack. SolarWinds. event-stream. ua-parser-js. xz-utils. The pattern is consistent: an attacker compromises something you depend on, and your application becomes the delivery mechanism for the attack. SAST and DAST do not catch this; the malicious dependency does what the package author intended.

## Key Points

- Commit the lockfile. Always.
- Build only with the lockfile. `npm ci` not `npm install`. `yarn install --frozen-lockfile`. `cargo build --locked`.
- Update the lockfile through a deliberate dependency-update process (Dependabot, Renovate), not as a side effect of unrelated changes.
- Review lockfile changes in PRs. Large lockfile diffs are a vehicle for malicious updates; the reviewer should be able to scan them.
- **Update through a bot, not manually**. The bot's PRs are reviewed. Manual updates can slip through.
- **Stage updates**: minor and patch updates auto-apply if tests pass; major updates require manual review.
- **Pin versions, not ranges**. Lockfiles do this for you. But the package.json should also use exact versions where you can stomach it.
- **Audit the package's reputation**. New, low-download packages are higher risk. Consider whether you need them at all.
- Pin compiler versions.
- Set SOURCE_DATE_EPOCH to the commit timestamp.
- Avoid embedding hostnames, dates, or random IDs in the artifact.
- Use deterministic file ordering.

The 2020s have been the decade of the supply-chain attack. SolarWinds. event-stream. ua-parser-js. xz-utils. The pattern is consistent: an attacker compromises something you depend on, and your application becomes the delivery mechanism for the attack. SAST and DAST do not catch this; the malicious dependency does what the package author intended.

Defending the supply chain is its own discipline. Different tools, different mental model, different gating points in the pipeline.

SBOM: Software Bill of Materials

The SBOM is a machine-readable inventory of every component in your software. Every direct dependency. Every transitive dependency. Every base-image layer. Every binary tool included in the build.

Generate an SBOM on every build. The format is standardized — CycloneDX or SPDX. Tools (Syft, Trivy, npm sbom, cargo sbom) produce SBOMs from your build artifacts.

Store SBOMs alongside the build artifacts. When a CVE is announced for a dependency, you can query: which of our deployed services include this dependency? With SBOMs, the query is a database lookup. Without, you're rebuilding everything to find out.

The SBOM should travel with the artifact. If you publish a container image, attach the SBOM as a manifest annotation or a sidecar artifact. If you publish a binary, publish the SBOM next to it. Consumers who care about your supply chain (enterprises, governments) will ask for it.

Artifact Signing

Sign every build artifact. The signature confirms two things: the artifact was produced by your build pipeline, and the artifact has not been modified since.

Use Sigstore (cosign) for container images. Use the same primitive for binaries, language packages, anything else you publish. Sigstore signs with short-lived OIDC-tied keys, so you don't have a long-lived signing key to lose.

The signature is verified at deploy. Your Kubernetes admission controller, your CI/CD deploy step, your customer's pull pipeline — they verify the signature against your public identity. An unsigned artifact, or one signed by an unexpected identity, is rejected.

Combine signing with provenance attestation: a signed statement describing how the artifact was built (which CI run, which commit, which builder image, which build steps). Provenance lets you confirm not just who signed but how they built. SLSA (Supply-chain Levels for Software Artifacts) describes the levels of provenance maturity; aim for SLSA Level 3 over time.

Dependency Lockfile Discipline

Lockfiles (package-lock.json, yarn.lock, Cargo.lock, go.sum, poetry.lock, requirements.txt with pinned versions) are the contract that your build is reproducible. Without them, every build can pull different transitive dependencies, and the malicious update lands without anyone noticing.

Rules:

• Commit the lockfile. Always.
• Build only with the lockfile. npm ci not npm install. yarn install --frozen-lockfile. cargo build --locked.
• Update the lockfile through a deliberate dependency-update process (Dependabot, Renovate), not as a side effect of unrelated changes.
• Review lockfile changes in PRs. Large lockfile diffs are a vehicle for malicious updates; the reviewer should be able to scan them.

Treat the lockfile as code. Do not regenerate it lightly. The drift between the lockfile in your branch and the lockfile in main is itself a signal worth reviewing.

Dependency Update Discipline

Updates are the surface area for supply-chain attacks. The attacker takes over a maintainer's account, pushes a malicious version, you pull it via your dependency-update bot.

Mitigations:

• Update through a bot, not manually. The bot's PRs are reviewed. Manual updates can slip through.
• Stage updates: minor and patch updates auto-apply if tests pass; major updates require manual review.
• Delay updates by 7 days. Most malicious package updates are caught within a week. Auto-update bots can be configured to wait. The 7-day window adds back some risk in exchange for catching most attacks.
• Pin versions, not ranges. Lockfiles do this for you. But the package.json should also use exact versions where you can stomach it.
• Audit the package's reputation. New, low-download packages are higher risk. Consider whether you need them at all.

For high-stakes dependencies (cryptography libraries, auth libraries, anything that touches secrets), apply extra scrutiny: pin to specific commits if the library is on GitHub, or require a security review before bumping the version.

Provenance and Build Reproducibility

A reproducible build means: given the same inputs (source code, dependencies, build tooling), the build produces byte-identical output. Reproducibility lets you verify that the artifact came from the source code claimed.

Most builds aren't reproducible by default — timestamps, build paths, parallelism affect the output. Make them reproducible incrementally:

• Pin compiler versions.
• Set SOURCE_DATE_EPOCH to the commit timestamp.
• Avoid embedding hostnames, dates, or random IDs in the artifact.
• Use deterministic file ordering.

Reproducibility is hard to achieve fully but valuable in pieces. Even partial reproducibility narrows the attack surface — if the build is reproducible up to a few timestamps, an attacker has fewer places to hide a malicious modification.

Build-Pipeline Hardening

The build pipeline itself is a target. If an attacker compromises the build, they compromise everything you ship. Harden it:

• Isolated builds. Each build runs in a fresh, ephemeral environment. No cross-build contamination.
• No secrets in build logs. Mask secrets carefully; review logs before publication.
• Minimal builder permissions. The CI job needs to read source and write artifacts; it does not need to access production. Use OIDC-based short-lived credentials.
• Two-person review for changes to the pipeline itself. The Jenkinsfile / GitHub Actions YAML is code; it gets reviewed like code.
• Audit logs for the CI system. Who triggered which build, who modified the pipeline, who downloaded which artifact.

Monitoring the Supply Chain

After deploy, monitor for new vulnerabilities affecting components you ship. Subscribe to advisories for your dependencies. Run periodic SBOM-based scans against your live services. Be ready to issue patches.

The mean time to patch a known-vulnerable dependency in production is the metric to track. Sub-24-hour for criticals. Sub-week for highs. Anything longer is a queue, not a process.

For language ecosystems where this is harder (older runtimes, vendored dependencies), invest in the tooling to make the patching cycle faster. The next supply-chain attack will not be polite about your timeline.

Vendor Risk Assessment

Third-party services are part of your supply chain even when they're not in your code. SaaS analytics, error tracking, auth providers — they have access to user data or sit in the request path. Assess them:

• What access do they have to your data?
• What is their security posture (SOC 2, ISO 27001, pen tests)?
• What happens if they're compromised? What's the blast radius for you?

Vendor security questionnaires are a baseline; they confirm the vendor has the certifications. Real assessment includes reading their architecture, understanding their access model, and considering what's exposed if they're breached.

For critical vendors, have a contingency plan. Switch costs vary; if you can't switch within a week, the vendor's security is your security.

Anti-Patterns

No SBOM. When the next dependency CVE drops, you can't tell which services are affected. The CVE response stretches from hours to weeks.

Lockfile not committed. Each build resolves dependencies fresh; the malicious update lands without anyone noticing. Commit the lockfile.

Long-lived signing keys. Stolen signing keys produce indistinguishable malicious artifacts. Use short-lived keys (Sigstore).

Manual dependency updates. Bot-PRs get reviewed; manual ones slip in. Use Dependabot or Renovate.

Build pipeline as a free-for-all. Anyone can modify the pipeline; secrets leak in logs; builds aren't isolated. Treat the pipeline as production.

No supply-chain monitoring. A CVE for one of your dependencies drops; you find out from a customer two weeks later. Subscribe to advisories; track MTTP.