Software Supply Chain Security

Supply chain attacks target the code and tools you trust: open-source dependencies, CI/CD pipelines, build systems, and package registries. The SolarWinds attack compromised 18,000 organizations through a single build system. The Log4Shell vulnerability (CVE-2021-44228) affected virtually every Java application. These aren’t edge cases — they’re the new normal.

---

Attack Vectors

Vector	Example	Impact
Dependency confusion	Attacker publishes malicious package with same name on public registry	Malware in your build
Typosquatting	reqeusts instead of requests	Credential theft
Compromised maintainer	Maintainer account hijacked	Backdoor in popular package
Build system compromise	CI/CD pipeline injected with malicious steps	Malicious artifacts deployed
Registry poisoning	Malicious image pushed to Docker Hub	Compromised containers

---

SLSA Framework

Level	Requirements	What It Prevents
SLSA 1	Build process documented	Untracked builds
SLSA 2	Version-controlled build, authenticated provenance	Tampered source
SLSA 3	Hardened build platform, non-falsifiable provenance	Compromised build
SLSA 4	Two-person review, hermetic builds	Insider threats

Build Provenance

# GitHub Actions with SLSA provenance
jobs:
  build:
    permissions:
      id-token: write     # OIDC token for signing
      contents: read
      attestations: write
    
    steps:
      - uses: actions/checkout@v4
      
      - name: Build artifact
        run: make build
      
      - name: Generate SBOM
        run: |
          syft . -o spdx-json > sbom.spdx.json
      
      - name: Attest build provenance
        uses: actions/attest-build-provenance@v1
        with:
          subject-path: 'dist/app'
      
      - name: Attest SBOM
        uses: actions/attest-sbom@v1
        with:
          subject-path: 'dist/app'
          sbom-path: 'sbom.spdx.json'

---

Dependency Management

# Dependabot configuration
version: 2
updates:
  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "weekly"
    open-pull-requests-limit: 10
    groups:
      production-dependencies:
        patterns: ["*"]
        exclude-patterns: ["@types/*", "eslint*", "jest*"]
        update-types: ["minor", "patch"]
    security-updates:
      enabled: true

Lockfile Best Practices

Practice	Why
Always commit lockfiles	Reproducible builds, prevent supply chain drift
Pin major versions	^1.0.0 allows minor updates, 1.0.0 pins exactly
Audit regularly	npm audit, pip audit, cargo audit
Use private registry	Mirror public packages, scan before allowing
Review new dependencies	Check maintenance status, download count, funding

---

Anti-Patterns

Anti-Pattern	Problem	Fix
No lockfile committed	Different builds get different dependencies	Commit and enforce lockfile usage
Blind dependency updates	Auto-merge without review	Review dependency diffs, especially new packages
No SBOM	Don’t know what’s in your software	Generate SBOM on every build
Trust-by-default for packages	Install anything from npm/PyPI	Private registry as proxy with scanning
Build on developer machines	No reproducibility or integrity	CI/CD builds only, hermetic builds

---

Checklist

• Dependency scanning: automated vulnerability scanning (Dependabot, Snyk)
• SBOM: generated and stored for every release
• Lockfiles: committed, enforced in CI
• Private registry: proxy for public packages with scanning
• Build provenance: SLSA Level 2+ with signed attestations
• Image signing: all container images signed (cosign, Notary)
• Dependency review: new dependencies reviewed before merging
• Pin dependencies: exact versions in production
• Audit schedule: weekly dependency vulnerability scans

---

:::note[Source] This guide is derived from operational intelligence at Garnet Grid Consulting. For supply chain security consulting, visit garnetgrid.com. :::