supply-chain

Supply Chain Security

Purpose

Reduce the risk that arrives through your dependencies and your build pipeline — which is now a more common attack path than a vulnerability in your own code.

When to Use

• Adding a dependency.
• Auditing an existing dependency tree.
• Hardening a CI/CD pipeline against compromise.
• Responding to a compromised or malicious package.

Capabilities

• Dependency vetting and risk assessment.
• Lockfile discipline and reproducible builds.
• SBOM generation and vulnerability scanning.
• Artifact signing and provenance attestation.
• CI pipeline hardening.

Inputs

• The dependency tree, direct and transitive.
• The build pipeline and its permissions.
• The advisory feeds relevant to your ecosystem.

Outputs

• A vetted dependency tree with a committed lockfile.
• An SBOM per build, and a scan that fails on critical findings.
• A pipeline where a compromised dependency cannot exfiltrate credentials.

Workflow

1. Vet before adding — Who maintains it? When was it last released? How many transitive dependencies does it drag in? A left-pad-sized utility with forty dependencies is a liability, not a convenience.
2. Commit the lockfile and install from it — npm ci, pip install -r requirements.lock, cargo --locked. An install that resolves versions at build time is an install that can pull a compromised patch release.
3. Pin CI actions by SHA — A tag is mutable. A compromised action with pull_request write access can exfiltrate every secret in the pipeline.
4. Restrict pipeline permissions — The build job does not need write access to the repository or production credentials. Scope tokens per job.
5. Generate an SBOM and scan it — On every build. Fail on critical vulnerabilities in what you actually ship, not in your dev dependencies.
6. Sign and attest — Sigstore/cosign for the artifact, with a provenance attestation linking it to the commit and the build.

Best Practices

• The most dangerous dependency is the one you did not choose: a transitive dependency four levels deep, maintained by nobody, that runs an install script.
• Install scripts (postinstall in npm, setup.py in pip) execute arbitrary code at install time, on developer machines and in CI. Disable them where you can (npm ci --ignore-scripts) and audit them where you cannot.
• Every dependency is code you ship and are responsible for. A 200-line utility is usually cheaper to write than to depend on.
• Typosquatting is real and effective. Check the package name character by character before adding it, especially in a hurry.
• A CI job that can both read a secret and reach the internet can exfiltrate that secret. Minimize the jobs that hold production credentials.
• Automated dependency-update PRs are good, but merging them without review is how a compromised patch release reaches production automatically.