Dependencies and the supply chain: governing what AI brings into your software

A component suggested by an agent enters a project in seconds. It will take weeks to leave, provided anyone still knows it is there. In between, it runs in production, most often with the same privileges as the application it serves. The question that matters is no longer just “is this component safe?”. It has become: who decided it would enter, and on what basis?

In AI-assisted development, that decision has changed hands without anyone formally recording it. The anchor piece of this series established the shift: the risk has left the network perimeter and settled into the software supply chain, the generated code, the dependencies, the build pipeline. The first piece dealt with the code AI writes. This one deals with what AI brings in: the third-party components it draws on, and the assembly that turns them into shipped software.

The thesis fits in one sentence: since the decision to admit a component has become a high-frequency machine flow, it can no longer be controlled after the fact, it is governed through an admission regime the system imposes. Four steps to get there: understanding what has changed in the decision itself, seeing the surface actually being run, setting the three controls of the admission regime, and making the build the place where provenance is proven.

An agent does not choose your components the way a developer does

Before AI assistance, adding a dependency was a discrete act. A developer would look for a library, compare two or three candidates, check the date of the last commit, sometimes the state of open issues, then own the choice in front of the team. The decision was slow, imperfect, but deliberate: it had an author, a moment, and it could be debated in review.

An agent does not proceed that way. It suggests a component because that component is statistically plausible in the context of the code in progress, and it does so dozens of times a day, as generation flows, with no comparison, no look at provenance, no trace of the alternative set aside. The admission decision no longer has an identifiable author or a dedicated moment: it is diluted into the production flow. The anchor piece flagged the limit case of this mechanic, the suggested component that does not yet exist and that an attacker registers to catch an expected suggestion. The common case is more mundane and more massive: legitimate components, entering without their entry ever being decided.

That shift makes after-the-fact control structurally insufficient. Code review, an indispensable link for reading what the machine wrote, does not catch what it imports: an import line is syntactically beyond reproach, and nothing in the diff signals the health of the package it pulls. As for the periodic dependency audit, it photographs a state the flow has already left behind by the time the report is read. An episodic control does not catch up with a continuous decision.

The point is not to take the tool away from teams: the speed gained is here to stay, and nobody will return to hand-picking every library. The point is to recognise that an architectural decision, what enters the foundation of the software, has been delegated to a machine by default. A delegation by default is not a policy.

What you run is not what you chose

Governing starts with seeing. The list of components a team believes it uses and the surface it actually runs are two different objects. Every installed library pulls in its own dependencies, which pull in others in turn: for a few dozen explicitly chosen packages, a project routinely runs several hundred. The anchor named this blind spot; the governance consequence deserves to be drawn in full: no serious decision can be made on a surface nobody can describe.

The instrument that makes that surface visible exists and has a name: the software bill of materials, or SBOM (the inventory of a piece of software’s components, versions and provenances included). The international baseline for the minimum elements of an SBOM, updated in 2026 and co-signed by agencies including France’s ANSSI, sets out the core: identification of each component, its version, its producer, and the dependency relationships between them. Nothing exotic: a standardised format that build tools know how to produce.

The frequent misunderstanding is to file the SBOM among compliance deliverables, a document produced to be archived. That is a misreading of what it is for. A current inventory is first an instrument of decision: the day a major vulnerability hits a widespread library, the difference between an organisation that answers “are we exposed, where, in which versions?” within two hours and one that launches three weeks of investigation comes down to the existence of that inventory. The first decides, the second endures.

In an AI-augmented context, the inventory also changes in nature. A written document would be stale before it was read; the inventory has to be generated by the build chain itself, at every construction, to keep pace with the incoming flow. It is the first stone of the admission regime: you can only admit or refuse what you can see entering.

The admission regime: three controls the system imposes

The second piece in this series set out the principle that commands everything else: faced with machine production, the control that holds is the one the system imposes, not the one an instruction requests. Applied to dependencies, that principle takes the form of an admission regime: three structural controls that act on the flow without demanding voluntary discipline from anyone, human or agent.

First control: where it comes from. The organisation defines the approved sources, in practice an internal registry or a proxy filtering the public repositories, and the system refuses by default whatever does not come from them. A package unknown to the registry does not install, however insistent the suggestion. This control mechanically neutralises illegitimate or hijacked components: the agent can suggest anything, only what has been admitted can enter.

Second control: nothing changes without a decision. Versions are locked, through lockfiles, integrity hashes and verified signatures, so that a version upgrade is an explicit, traced and attributable act, never the side effect of a reinstall. This control turns the silent drift of versions into a series of visible decisions, which can be grouped, scheduled and reviewed.

Third control: the state is checked at every build. Software composition analysis, whose principle the anchor set out, stops being a periodic audit and becomes a pipeline gate: every build matches the dependency tree against databases of known vulnerabilities, and blocks beyond a severity threshold set by management, not by the team case by case. The threshold is a policy; its application is mechanical; its exceptions are recorded decisions, with an owner and a deadline.

The coherence of these three controls is what makes them effective. Each one acts at the moment the flow passes, not after; none relies on an individual’s vigilance; and the agent is subject to them just like the developer, which is exactly the point. It is also what sets them apart from an end-of-line audit: they do not slow production down, they bound its playing field. A team working inside the admission regime keeps all of its speed; simply, what it produces is admissible by construction.

The build, the last point where provenance can be proven

There remains the moment where everything converges: the construction that turns the code and its components into a shipped artefact. The anchor covered securing that chain, its privileges, its secrets, the control of what runs in it. The question here is different and complementary: what can be proven about what comes out of it?

A build artefact is opaque by nature. Once built, nothing in the binary or the archive says which commit it comes from, with which dependencies it was assembled, or through which chain. That opacity becomes a governance problem the day you have to answer, in front of a client, an insurer or a regulator, the question: what exactly does what you shipped contain? Answering by reconstruction after the fact is slow and uncertain. Answering with proof requires having had that proof produced at build time.

That is the purpose of provenance attestations: signed metadata, generated by the build chain, linking the artefact to its source commit, its component inventory and the steps that produced it. The SLSA framework (Supply-chain Levels for Software Artifacts) makes them the core of a progressive maturity model: you do not demand everything on day one, you climb levels, from simple traceability to proof that is hard to falsify. For a management team, the value of the model lies precisely in its gradation: it turns “securing the supply chain” into a staged path rather than an all-or-nothing programme.

This link closes the loop the prototype opened. An AI-built prototype holds up in a demo without proving anything about what it embeds; a business application in production must be able to establish, at any moment, what it is made of and where that came from. The distance between the two is exactly what the admission regime and provenance come to close.

Who decides what enters your build?

The question deserves to be put exactly like that to the steering committee. If the honest answer is “the agent, as it goes, and the team when it thinks of it”, then the admission regime does not exist yet, and the surface running in production has no owner. There is nothing culpable about that finding: it is the default state of most organisations that adopted assisted development without revisiting their sourcing governance. A default state, however, is not a decision.

Taking that decision back requires no arsenal: an inventory generated at every build, approved sources, locked versions, a composition gate in the pipeline, attested provenance. Every element exists off the shelf, tools up without bespoke development and is imposed once and for all. What is most often missing is the initial act of governance: deciding that what enters the software gets decided, and entrusting the system, rather than everyone’s vigilance, with enforcing that choice.

The series’ perimeter closes here. Generated code gets read, control gets imposed, and what enters the build gets admitted under a regime whose overall frame was set by securing a business application built with AI: governing the software factory with the seriousness once reserved for the network.