IntermediateSupply Chain Security

Pin dependencies to exact versions with hash verification in all production lockfiles

npm install without a lockfile, or pip install without hash verification, installs "latest" — which could be a malicious package that was uploaded minutes ago. The PyPI typosquatting campaigns uploaded hundreds of packages with names nearly identical to popular libraries. Dependency pinning (exact version numbers) prevents automatic upgrades to compromised versions. Hash verification (SHA-256 hashes of each package in the lockfile) ensures the package you install is byte-for-byte identical to what you tested. Use npm ci (instead of npm install) in CI/CD, which enforces lockfile integrity. Use pip install --require-hashes for Python.

More in Supply Chain Security

All guides

intermediate

Pin GitHub Actions to specific commit SHAs, never to floating version tags

GitHub Actions version tags (uses: actions/checkout@v4) are mutable — the action maintainer can change what v4 points to at any time, or have their account compromised. The tj-actions breach demonstrated this: a compromised action was immediately applied to all 23,000 repositories using it via floating tag. Pin actions to the specific commit SHA that you have reviewed (uses: actions/checkout@abc123def456). The full SHA is immutable — it cannot be changed retroactively. Use a tool like Dependabot or Renovate to open pull requests when pinned SHA versions need updating, giving you review control.

See: GitHub Actions tj-actions BreachSupply Chain Security

advanced

Treat your build environment as production — harden it with the same controls

The CCleaner backdoor, the 3CX supply chain attack, and the ASUS ShadowHammer operation all shared the same root cause: attackers compromised the build server or developer machine that compiled the final software. The build environment is where your trusted code signing happens, where clean source becomes signed binaries. Harden build servers: restrict access to the minimum set of people, use ephemeral build environments that are destroyed after each build, require MFA for all access, enable audit logging, and isolate build networks from general corporate networks. A compromise of your build environment is a compromise of every piece of software you ship.

See: CCleaner BackdoorSupply Chain Security

advanced

Generate and publish a Software Bill of Materials (SBOM) for every release

A Software Bill of Materials (SBOM) is a machine-readable inventory of every component in your software: libraries, frameworks, direct and transitive dependencies. When a new vulnerability is disclosed (Log4Shell, Spring4Shell, Heartbleed), an SBOM lets you answer "are we affected?" in minutes rather than days of manual code archaeology. The White House Executive Order 14028 requires SBOMs for software sold to the US federal government. Generate SBOMs using Syft, CycloneDX, or SPDX tools as part of your build pipeline. Store them alongside each release artifact. Subscribe to CVE feeds and cross-reference against your SBOM inventory automatically.

See: Log4ShellSupply Chain Security