advanced
2 min answer
A data-protection platform depends on hundreds of third-party libraries. What controls meaningfully reduce supply chain risk, and which are theatre?
Show the full answer Hide the answer
What meaningfully reduces risk
- A complete, current inventory of what you actually ship, generated from the build rather than maintained by hand. Without it, the response to a disclosed vulnerability is a search rather than a query, and the difference is days.
- Pinned, verified dependencies with lock files and integrity hashes, so the artefact built today is the artefact built tomorrow and a compromised registry cannot silently substitute.
- Build provenance: a signed attestation of what source produced which artefact, on which builder. This is what makes "was this artefact built from our code" answerable, and it is the control that addresses build system compromise rather than dependency compromise.
- Isolated build environments with no ambient credentials, since a build that can reach production secrets turns any dependency into a path to them.
- Restricting what dependencies can do at runtime — network egress controls, filesystem restrictions — which limits the value of a compromise regardless of how it arrived.
- A fast patch path, because the interval between disclosure and exploitation is short and the constraint is usually deployment speed rather than detection.
What is closer to theatre
- Vulnerability scanning that produces a report nobody triages. The finding count is not a security outcome; the time to remediate exploitable findings is.
- Blocking builds on any vulnerability of any severity, which produces so much noise that teams add blanket exceptions and the control stops operating.
- An inventory document maintained manually, which is wrong within a sprint.
- Policies requiring approval for new dependencies with no tooling, which is bypassed by copying code instead.
The distinction that matters
Reachability. A vulnerability in a code path your application never calls is a different risk from one in the request-handling path, and treating them identically is why vulnerability management is mostly noise. Prioritising by reachability and exploitability, rather than by severity score, is what makes the process survivable.
The control most often missing
A dependency's own trust decision. Someone should be able to answer why a given library is in the product, who evaluated it, and what would happen if it were abandoned or compromised. For a data-protection platform, a compromised dependency in the backup agent is a route into every customer's estate — which makes the inventory question a genuine architectural concern rather than a compliance one.