Supply Chain Security Fundamentals

Only 11% of UK organisations review cyber security risk in their supply chains. As supply chain attacks grow in frequency and regulatory mandates expand (NIS2, Cyber Essentials in procurement), development teams need practical controls - not just awareness.

This guide covers what you can do today to reduce supply chain risk across your dependencies, build tools, and upstream suppliers.

What is software supply chain security?

Your software supply chain is everything that contributes to your deployed application that you did not write yourself:

• Open source dependencies - npm, PyPI, Maven, crates.io packages
• Container base images - OS layers, runtime images
• Build tools - compilers, bundlers, CI runners, GitHub Actions
• SaaS integrations - APIs, webhooks, OAuth providers
• Infrastructure providers - cloud platforms, CDNs, DNS
• Human contributors - maintainers of packages you depend on

An attacker who compromises any of these can inject code into your application without touching your repository.

Reference: NCSC - Supply Chain Security Guidance Reference: SLSA - Supply-chain Levels for Software Artifacts

Dependency management

Pin and lock everything

Lock files (package-lock.json, pnpm-lock.yaml, poetry.lock, Cargo.lock) ensure that every build uses the exact same dependency versions. Without them, a compromised package update can silently enter your build.

• Lock files are committed to version control
• CI installs dependencies using the lock file (npm ci, not npm install)
• Direct and transitive dependencies are resolved to exact versions

// package.json - pin major versions, let lock file handle the rest
{
  "dependencies": {
    "express": "^4.21.0",
    "zod": "^3.23.0"
  }
}

Automated updates with review

Use Dependabot or Renovate to create PRs for dependency updates. Do not auto-merge major or minor updates without review.

• Automated dependency update tool is enabled
• Patch updates are auto-merged (low risk, high volume)
• Minor and major updates require human review
• Updates to security-critical packages (auth, crypto, parsing) always require review
• Teams have a defined SLA for reviewing dependency update PRs

Scan for known vulnerabilities

• Software Composition Analysis (SCA) runs on every PR
• Critical/high severity findings block merges
• An exceptions process exists for known CVEs that cannot be immediately resolved
• Transitive dependency vulnerabilities are tracked, not just direct ones

# GitHub Actions - fail on high+ vulnerabilities
- name: Audit
  run: npm audit --audit-level=high --omit=dev

Software Bill of Materials (SBOM)

An SBOM is a machine-readable inventory of every component in your software. It answers: "what did we ship, and what versions?"

SBOMs are increasingly required by procurement frameworks, government contracts, and regulatory regimes. They are also essential for incident response - when a new CVE is published, you need to know within minutes whether you are affected.

Generating SBOMs

Generate SBOMs as part of your build pipeline, not manually:

# CycloneDX for Node.js
npx @cyclonedx/cyclonedx-npm --output-file sbom.json

# Syft for container images
syft your-image:latest -o cyclonedx-json > sbom.json

• SBOMs are generated automatically in CI
• SBOM format is CycloneDX or SPDX (machine-readable, industry standard)
• SBOMs are stored alongside release artifacts
• SBOMs cover both application dependencies and container/OS packages

Using SBOMs for incident response

When a critical CVE is published:

1. Search your stored SBOMs for the affected package and version range
2. Identify which deployed services are affected
3. Prioritise patching based on exposure (internet-facing > internal)
4. Verify the fix with a fresh SBOM from the patched build

Without SBOMs, step 1 becomes "ask every team if they use this package" - which is slow, unreliable, and does not scale.

Build provenance and signing

Provenance answers: "where did this artifact come from, and has it been tampered with?"

Container image signing

• Production images are signed after building
• Deployment pipelines verify signatures before deploying
• Unsigned or tampered images are rejected

# Sign with cosign (Sigstore)
cosign sign --yes your-registry/your-image:sha256-abc123

# Verify before deploy
cosign verify your-registry/your-image:sha256-abc123

SLSA levels

SLSA (Supply-chain Levels for Software Artifacts) defines a maturity framework for build integrity:

Most teams should aim for SLSA 2 as a baseline - builds happen in CI, not on developer machines, and build logs are retained.

Reference: SLSA Specification

CI/CD pipeline security

Your CI/CD pipeline is part of your supply chain. If an attacker compromises it, they can inject code into every deployment.

• CI runners use ephemeral, isolated environments (not shared, long-lived VMs)
• Third-party GitHub Actions and CI plugins are pinned to a specific commit SHA, not a mutable tag
• CI secrets are scoped to the repositories and environments that need them
• Pipeline definitions are code-reviewed like application code
• Self-hosted runners are hardened and regularly rebuilt

# Pin actions to commit SHA - tags can be moved
- uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # v4.2.2

Common failure: Pinning to @v4 instead of a commit SHA. If the action's repository is compromised, the tag can be pointed at malicious code.

Supplier assessment

For SaaS providers, APIs, and infrastructure vendors:

• Critical suppliers are identified and documented
• Security practices of critical suppliers are reviewed (SOC 2, ISO 27001, penetration test reports)
• Contracts include security requirements and incident notification obligations
• Fallback plans exist for critical supplier outages or compromises
• Webhook endpoints validate signatures from upstream providers

This does not require a formal supply chain risk management programme - start with a simple spreadsheet listing your critical suppliers, what data they access, and when you last reviewed their security posture.

Regulatory context

If you sell to government, regulated industries, or EU markets, supply chain security controls are becoming non-negotiable.

Quick-start checklist

1. Lock files committed, npm ci in CI
2. SCA scanning on every PR with merge blocking
3. Dependabot/Renovate enabled with review SLAs
4. SBOM generated in CI alongside builds
5. Container images signed and verified
6. CI actions pinned to commit SHAs
7. Critical suppliers listed with review dates

Further reading

• NCSC - Supply Chain Security
• SLSA - Supply-chain Levels for Software Artifacts
• OpenSSF - Scorecards
• CycloneDX - SBOM Specification