Supply chain risk before the SBOM era: why dependencies need to be tracked systematically now
Opaque transitive dependencies are not an academic problem. They are already an active attack vector.
When a company buys software or pulls in a ready-made library, it thinks about what it is getting. Rarely does anyone think about what comes along with it: what other components are embedded inside, who wrote them, when they were last updated, and whether they contain known vulnerabilities.
That is the software supply chain problem. It is not new. But the scale at which code is reused today makes it considerably sharper than it was five years ago.
How the problem is structured
A modern application is not made of code written by one team alone. A typical Java or Python project has dozens of direct dependencies, each of which pulls its own - and so on recursively. The real dependency tree of a small project can easily contain several hundred components.
Most of them no one on the team has ever read. They are pulled in because they solve a problem - XML parsing, date handling, an HTTP client. Trust in them is based on reputation and popularity, not a code audit.
An attacker who wants to get into a system may choose to go through one of those dependencies rather than through the main application. If there is a vulnerability in a popular library, it is immediately present in every project that uses it - the same logic behind trusting the software delivery channel that the Flame incident exposed at the level of operating system updates.
What has already happened
Compromise through dependencies is not hypothetical. Incidents involving malicious code inserted into open-source packages have already been documented - still rare, not yet widely covered. But the vector is clear: if someone controls a popular package, they control a small piece of code in a very large number of systems.
A separate issue - not deliberate attacks, but simply unpatched vulnerabilities. A library with a known CVE can remain in production for years if nobody systematically tracks the state of dependencies. That is not a theoretical risk - it is the routine situation in most projects.
What systematic dependency tracking looks like
A systematic approach to dependencies is not paranoia and does not require auditing every line of someone else's code. It is a few concrete practices.
Know what you have. The list of all direct and transitive dependencies should be explicit, not an implicit side-effect of the build. Tools for this exist across ecosystems - Maven and Gradle in Java, pip freeze in Python, and others.
Track known vulnerabilities. CVE databases are public. Tools that match a dependency list against a vulnerability database already exist, even if they have not become standard yet. Running such a check at build time is not complicated.
Understand provenance. Where does a package come from? Who maintains it? When was it last updated? If the answers are "we don't know", that is a risk worth consciously evaluating.
Manage updates deliberately. Indefinitely deferring dependency updates is technical debt with a non-zero security cost. A regular update process is better than an emergency upgrade after a critical CVE is published.
Practical questions
A few questions help assess the situation in a specific organisation:
- Do we have a list of all components in production systems - not just our own code?
- Is there a process that responds when a critical vulnerability in a popular library is published?
- Who decides whether to use a new external package?
- How long does an unpatched vulnerability in our dependencies typically live?
- Is there isolation between components - or does compromising one dependency give access to everything?
Industry standards and tools for systematically managing software composition will come later. But waiting for them to start thinking about this is not necessary.