Install a mainstream JavaScript framework and a handful of common libraries, and the resulting dependency tree runs to somewhere between 800 and 1,500 packages. A team might have deliberately evaluated fifteen of them. The rest arrived as transitive dependencies, chosen by other maintainers for their own reasons, and every one of them executes with the same privileges as the code that was reviewed.
That asymmetry is the whole of software supply chain risk. The xz utils backdoor in 2024 was the clearest illustration: a maintainer account cultivated over two years, a payload hidden in test fixtures, and a compromise that reached the edge of most Linux distributions before an engineer noticed a half-second delay in an SSH login.
What an SBOM Is For
A software bill of materials is an inventory of every component in a build, with versions, licences and relationships. In the United States it became a procurement expectation through Executive Order 14028, and it is increasingly appearing in enterprise vendor questionnaires in India as well. Two formats matter in practice: SPDX and CycloneDX, both machine readable, both supported by mainstream tooling.
The value is not the document. The value is the query it makes possible. When the next critical vulnerability lands in a widely used logging or serialisation library, the question is always the same: are we running it, in which services, at which versions. Organisations with generated SBOMs answer that in minutes. Organisations without them spend three days grepping repositories and are never entirely confident in the answer.
Generate it in continuous integration for every build, attach it to the artifact, and store it alongside the deployment record. An SBOM produced by hand once a year describes a build that no longer exists.
The Controls Worth Having
- Pin and lock everything. Commit lockfiles and pin base images by digest rather than tag. A tag is a moving reference, which means a rebuild can silently pull different code than the one that passed review.
- Verify provenance. Build attestations following the SLSA framework let you confirm that an artifact came from the source you think it did, built by the pipeline you think built it. This is the control that would have mattered in several recent compromises.
- Watch for the install-time hooks. Post-install scripts in package managers run arbitrary code on developer machines and build agents. Disabling them by default and allowlisting the few packages that genuinely need them removes a large and frequently used attack path.
- Set a patch clock, not a patch wish. Agree service levels by severity, for instance seven days for critical and thirty for high, and measure against them. Unmeasured intent decays quietly.
- Treat maintenance signals as risk data. A package with a single maintainer, no release in three years and a million weekly downloads is a supply chain risk regardless of whether it currently has a CVE.
Triage Beats Total Coverage
Turn on a scanner across a mature codebase and it will report several hundred findings within the hour. Teams that try to clear the list wholesale usually abandon the effort within a month.
Reachability analysis is what makes the volume manageable. A vulnerability in a code path your application never calls is real but not urgent, while a medium severity issue in your request parsing is the opposite. Modern tooling can distinguish these, and the practical effect is often a 60 to 80 percent reduction in what genuinely needs attention this week. Combine that with exploit prediction scores rather than raw CVSS, and the remaining queue is short enough that people actually work it.
At Invexa, dependency inventory and provenance are part of how we set up a build pipeline rather than something added when a client questionnaire arrives. Knowing exactly what shipped, and being able to prove where it came from, is the precondition for responding to anything.