Supply Chain¶
Supply Chain is the condition that asks one question: do you know what is inside what you shipped? Every modern build pulls in code you did not write, the third-party libraries, base images, sidecars, and a transitive dependency four levels down that you have never once opened. Once you embed it, you ship it as if it were your own, and the liability is yours from that moment on.
The question now reaches past code. A modern build also ships model weights you did not train, datasets you did not assemble, and the pieces an agent pulls in to do its work: the skills it loads, the tools it calls, the MCP servers it connects to. Each one you embed and then ship as your own, the same as any library, and the liability arrives with it. These resist inventory harder than code does. An agent's tools tend to self-install, self-update, and connect at runtime, often outside whatever software intake process you thought you had. And a model weight arrives as an opaque blob you cannot read or rebuild from source, whose origins you take on trust. The surface widened faster than the practice did. The discipline does not change: know what is inside, and refuse to ship what you cannot account for.
Some of what you embed does not sit still. An agent's tools and MCP servers reach out at runtime to dependencies of their own, pulled in past whatever intake you thought you had, so the thing you shipped is operating sub-dependencies you never reviewed. That is the operator beneath the operator seen from the supply side: a delegated dependency, embedded.
This is the condition you can do the most about, because the artifact is in your hands. You can read it, generate an SBOM, sign it, pin it, rebuild it from source. Supply Chain is soil. You can amend it. The way it fails is almost always the same: you did not look.
Why it is the loudest of the four¶
Supply Chain has been the one to watch for years, roughly since 2017, when adversaries moved discovery to automation at internet scale and began finding vulnerable dependencies faster than defenders could inventory them. The asymmetry is the whole problem. An attacker runs continuous, internet-wide scans for a known-vulnerable package. A defender who inventories dependencies once a quarter is answering last quarter's question.
This is a matter of tempo. Supply Chain does not matter more than the rest; it degrades faster and gets exploited sooner, so it earns first call on attention and budget. Treat it as the default #1 and argue yourself down from there if your context warrants.
The asymmetry that earns it the slot is that adversaries scan faster than defenders inventory. If build-generated inventory ever becomes universal and continuous, that gap narrows and the call would have to be re-argued. Abandonment is the part that would survive the change, because knowing which orphaned package you depend on does not make it maintained.
What cultivating it looks like¶
Tending Supply Chain is the practice of comprehension: closing the gap between what you shipped and what you actually understand about it. That gap is widening on its own, as more of the code entering your artifacts is generated faster than anyone reads it. The Coadaptive Security layer takes up that pressure directly. Here it is enough to say the lever is comprehension, and the work is refusing to ship what you have not understood.
- Inventory, continuously. A complete, current picture of direct and transitive dependencies, generated by the build rather than maintained by hand. The SBOM is the artifact; the comprehension is the point.
- Establish provenance and sign. Know where each artifact came from and that it arrived unaltered. Verified provenance turns "we think this is the library we meant" into something you can check.
- Pin and rebuild. Pin versions so a dependency cannot change under you silently. Rebuild from source where the supply matters enough to warrant it.
- Catch the supply-specific attacks. Dependency confusion, typosquatting, a compromised maintainer pushing a poisoned release, and now a poisoned MCP server or a tool whose description carries instructions the model will follow. They are attacks on your trust rather than bugs in your code, which is why your own tests never catch them.
- Weigh survivability alongside security. A dependency's future is part of its risk. Take it on partly on whether the project is alive and whether you could carry it if the upstream stopped.
None of this is a control you install once. A dependency you vetted last year is a dependency that has shipped forty releases since. Comprehension is a standing practice or it is nothing.
When no one is left to tend it¶
The practices so far assume the thing you embedded keeps shipping. You inventory it, sign it, pin it, and wait for the next release to patch. But a dependency can fail in a way none of that touches: it can simply stop. The maintainer walks away, the project is archived, the company behind it folds or sells and the buyer turns it off. The code still sits in your tree doing its job, until the day a vulnerability lands in it and no fix is ever coming.
This is a different failure from a breach. A poisoned release is an attack on your trust; an abandoned dependency is the absence of anyone to trust. None of the breach-facing controls reach it. An SBOM tells you that you depend on the orphaned package; it says nothing about keeping it alive. A signature proves the last release was genuine and promises nothing about the next. Against a vendor that no longer exists, an indemnity is a claim on an empty estate.
core-js sits in a large share of the web, downloaded billions of times, and is maintained by one person who has said the money to keep it going has collapsed and that he is ready to walk. Nothing was breached. The risk is that a load-bearing dependency rests on a single human, and the bus factor upstream is one.
With open source you always have the right to fork. What you rarely have is the capacity to maintain what you forked. Forking core-js means owning a polyfill library you did not write and cannot staff. So the real question is your own bus factor on a dependency whose upstream bus factor is one, and you answer it before the abandonment, while there is still time. Vendor the source so you can patch it yourself when no one upstream will. Weigh how alive a project is before you take it on: the release cadence, the number of hands, whether a foundation stands behind it or one tired person does. Funding the maintainer can buy time, but it buys goodwill rather than a control.
That is the embedded version. A delegated vendor can die the same way, on a deadline or in a bankruptcy, and because that is Third-Party the continuity plan for it is built there.
Containment does not save you from abandonment. This is a continuity problem rather than a blast-radius one, carried by source escrow, the contractual right to fork or self-host, and your own capacity to take the code over, planned before you need it rather than improvised the week the upstream goes quiet.
How tending differs by position¶
The condition is the same everywhere; the way you can sustain it is not. A Craft shop tends Supply Chain with a single well-chosen managed scanner and a short list of vetted dependencies. A Lean enterprise tends it with a platform team, a dependency proxy, and a paved road that makes the secure choice the default choice. The Craft shop that reaches for the Lean enterprise's toolchain will drown in alerts it cannot triage. Match the practice to what your position can actually keep alive.
Where it shows up¶
A weak Supply Chain condition rarely announces itself in Supply Chain. It surfaces at Runtime, as the incident you trace back to a dependency you never inventoried. And it is cultivated, or skipped, in Process: a build pipeline that emits provenance and an SBOM as a byproduct is tending Supply Chain for free.