Supply Chain Security for Teams That Ship Daily
Most of your codebase is code you did not write. Securing it does not require slowing down. It requires knowing what you depend on and controlling how it changes.
Open a typical application repository and count the lines your team wrote against the lines in the dependency tree. The ratio is usually somewhere between one in fifty and one in a thousand. Almost everything running in production was written by strangers, and the security programme frequently focuses on the small part you control.
This is not an argument for writing everything yourself. It is an argument for treating dependencies as what they are: production infrastructure with an unknown maintenance status.
Know what you actually run
The first question in any incident involving a vulnerable package is: do we use it, and where? Organisations that cannot answer within minutes spend the first day of the response doing archaeology instead of remediation.
A software bill of materials, generated at build time and stored with the artefact, answers this. Not a periodic scan of source repositories, which misses transitive dependencies and drifts immediately, but a record of what actually went into the thing you deployed.
- Generate the SBOM in the build, not afterwards. It should describe the artefact that shipped, not a scan of the repository some time later.
- Store it with the artefact. An SBOM in a separate system that cannot be joined back to a running deployment answers the wrong question.
- Include transitive dependencies. The direct dependency list is the least interesting part; the risk almost always lives several levels down.
Control how dependencies change
Most supply chain compromises exploit the update path rather than the package itself. A dependency you audited last quarter can become hostile with a patch release if you accept updates automatically without review.
- Commit lockfiles and mean it. Every environment installs exactly what was tested. A version range that resolves differently in CI and production is a reproducibility problem before it is a security one.
- Pin your build tooling too. The CI image, the compiler, the action or plugin references. A build pipeline that pulls a mutable tag is running unreviewed code with credentials.
- Separate the update decision from the update. Automated pull requests that raise a version are good. Automated merges of them are a policy decision that deserves an explicit owner, not a default.
- Prefer fewer, better-maintained dependencies. Every package is a trust relationship. A utility saving twenty lines is rarely worth an unbounded one.
You cannot audit your way out of a dependency tree with ten thousand nodes. You can control how that tree changes.
Provenance: prove the artefact came from the source
The step teams reach last is establishing that the artefact in the registry was built from the commit it claims, by the pipeline it claims. Without it, a compromised build environment is undetectable. The code review process signs off on source that is not what gets deployed.
Signing build artefacts and verifying signatures at deploy time closes this. It is more approachable than it was a few years ago, and the meaningful work is usually organisational: deciding what your policy is when verification fails, and being willing to block a deploy on it.
A patching policy that survives contact with reality
The common policy, all critical vulnerabilities patched within seven days, produces alert fatigue and quiet non-compliance, because most findings are not exploitable in your context and teams learn to ignore the queue.
Severity in the abstract is not risk in your system. A critical vulnerability in a code path you never call, in a service with no network exposure, is genuinely less urgent than a moderate one in your authentication flow. A policy that cannot express this trains people to ignore it.
- Triage by reachability and exposure, not by score alone. Is the vulnerable function actually called? Is the service reachable from outside?
- Set different clocks for different tiers. Internet-facing services handling sensitive data warrant an aggressive clock. An internal batch job does not need the same one.
- Track the backlog trend, not the absolute count. The count is never zero. Whether it is growing or shrinking is the number that tells you something.
The aim is a queue that a team can plausibly clear, so that the alerts continue to mean something. A policy people follow imperfectly is worth more than one they abandon entirely.