Securing the Software Supply Chain

Defend against compromised packages and builds

Supply-chain attacks include typosquatted or hijacked packages, dependency confusion (a public package with an internal package's name), malicious install scripts and compromised build systems. Defences: commit lock files and pin versions, use a private registry or proxy with scoped package names, review new dependencies, disable or restrict install scripts where possible, pin CI actions to commit SHAs, sign artefacts and record provenance (for example with Sigstore and SLSA levels), and give build jobs only the permissions they need.

Hardening a CI workflow

GitHub Actions example.

permissions:
  contents: read                    # least privilege by default

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      # pin third-party actions to a full commit SHA, not a moving tag
      - uses: actions/checkout@<full-commit-sha>
      - run: npm ci                   # installs exactly what package-lock.json specifies
      - run: npm audit --omit=dev --audit-level=high

Use npm ci, not npm install, in CI

npm ci fails if the lock file and package.json disagree, so builds are reproducible.

Quick check: What is dependency confusion?

• A public package published with the same name as an internal one so builds fetch the attacker's version
• Two developers editing the same file
• Using too many libraries
• A circular import