Chapter 03 · Part I — The case
Why current controls fall short
An honest evaluation of the tools in common use — static analysis, software composition analysis, review, penetration testing, accreditation — and the specific point at which each one runs out.
Every control below is worth having, and none of them should be removed. This chapter is not an argument that your security programme is wrong. It is an argument that each control has a defined edge, that machine authorship pushes work past that edge faster than the control can follow, and that the gap is structural rather than a matter of tuning.
Section 01Static analysis
What it does well. Finds known-shaped defects cheaply and repeatably, at a point in the lifecycle where fixing them is inexpensive. For well-characterised classes it is genuinely effective and should stay.
Where it runs out. A scanner searches for the presence of a pattern. It cannot establish the absence of a capability. It will tell you that a query looks unparameterised; it cannot tell you that this component is incapable of reaching the database at all, because nothing in the language expresses that. So its output is a list of findings to triage, with a false-negative rate nobody can quantify — and under machine authorship the queue grows with output volume while the triage capacity does not.
The deeper issue is the shape of the answer. A scan result is probabilistic evidence about a specific artifact at a specific moment. An accreditation, an audit, and an adversary all want a property that holds for the system by construction.
Section 02Software composition analysis and SBOMs
What it does well. Inventories what you depend on and matches it against known-vulnerability data. Indispensable for response: when an advisory lands, you need to know within minutes whether you are exposed.
Where it runs out. Three places, and each is visible in the incident record from the previous chapter.
- It is retrospective by construction. It matches against what is already known to be bad. The self-replicating package worm and the first malicious tool servers were novel at the point of maximum damage.[7]
- It inventories components, not permissions. An SBOM tells you a package is present. It does not tell you that the package opened a network socket during your build, because in the incumbent model that is not a declared property of anything.
- It cannot see the build itself. Where installation executes vendor-supplied code with the privileges of the machine doing the install, the compromise happens before any artifact exists to inventory.[6]
Section 03Human code review
What it does well. Catches intent-level and design-level problems no tool can: this is the wrong approach, this misunderstands the regulation, this will not work at scale. That is irreplaceable and should absorb more of your reviewers' attention, not less.
Where it runs out. Capacity, and it is arithmetic rather than diligence. Machine-authored change arrives faster than human attention can absorb it, and the gap widens with every capability improvement. Review that cannot keep pace is not a control; it is a queue with a governance label.
The automated substitute has a measured ceiling. In the first sabotage-and-monitoring evaluation, the best monitor reached respectable discrimination — but catching 80 per cent of sabotage attempts would have required a false-positive rate of 20 to 40 per cent.[10] No organisation operates at that rate, so in practice the threshold gets set where the alert volume is tolerable, which is well below where the coverage is meaningful.
Section 04Penetration testing and red teaming
What it does well. Produces genuine adversarial evidence, finds chains that no scanner models, and is the only control on this list that tests the system as an attacker actually encounters it.
Where it runs out. Cadence and coverage. A test is a sample, taken at a moment, of a system that now changes continuously. It establishes that a specific attacker did not find a specific thing in a bounded window. When the release cadence was quarterly, an annual test was a reasonable approximation. Where change is continuous and machine-generated, the interval between assurance events is where the risk accumulates — and the sample is drawn from a population that has since been replaced.
Section 05Accreditation and control frameworks
What they do well. Force explicit ownership of risk, produce a defensible record, and make an organisation's security posture legible to an outside party. In regulated and national-security contexts they are non-negotiable and correctly so.
Where they run out. They assess a system at a point in time and grant a status that persists. That is a reasonable model when the system changes slowly and every change passes through a human gate. It is under visible strain when the rate of change is set by a machine.
The direction of regulatory travel makes this sharper rather than softer. A 2026 supervisory position on immutable ledgers held that erasure must be complied with by design, and that technical impossibility is not a defence.[19] Read plainly, that is a statement that architecture has become a compliance surface — and architecture is exactly what a point-in-time control assessment is least equipped to evaluate.
Section 06Sandboxing and agent guardrails
What it does well. Bounds the damage an agent can do to the machine it is running on, and is the correct first move for anyone deploying coding agents today.
Where it runs out. The boundary is the process, and everything interesting happens inside it. An agent sandboxed to a repository still has the repository, the credentials in its environment, the network its build uses, and the authority of every dependency it pulls. Two serious attempts to make permissions finer-grained after the fact have already demonstrated the limit: process-granular flags cannot express this module may reach this resource, and a runtime permission architecture in another major platform was ultimately withdrawn after years of effort.
The lesson both teach is the same, and it is the pivot of this whole briefing: per-component authority cannot be expressed at process granularity and cannot be retrofitted at runtime. It has to be a static property that a checker enforces.
Section 07The pattern across all six
Every control in common use is a form of inspection. All of them answer "did we find something wrong?" None answers "is this wrong thing possible?"
That distinction has been tolerable because the volume of code was bounded by the number of engineers writing it. It is the assumption machine authorship removes. Layering more inspection onto a foundation that permits the failure raises the cost of each attack; it does not convert any of these controls into a guarantee, however many are added.
The incumbent ecosystem is improving on exactly these points. Several major package managers now disable install scripts by default; release-age cooldowns shipped across four package managers; trusted publishing and transparency logs are maturing; reproducible builds are becoming routine.[17] Each of those materially raises the cost of an attack described here.
Our claim is narrower than "the current stack is broken". It is that the properties creating the exposure are structural — ambient authority, install-time execution, mutable name resolution, hand-maintained tier boundaries — and that mitigations layered above a permissive foundation do not become guarantees. Where a control can be adopted rather than rebuilt, this programme adopts it: the registry model, the transparency log, the cooldown defaults and the reproducible-build discipline are all borrowed rather than invented.
Section 08What the alternative has to look like
If inspection is the limit, the alternative has to satisfy four conditions. They are the specification for the rest of this briefing.
- Authority is enumerable. It must be possible to ask what a component can reach and get a complete, checked answer — not an inference from what it appears to import.
- Guarantees survive the author being wrong. The property must hold whether or not the code was written by a competent engineer, a distracted one, or a model under someone else's influence.
- Evidence is generated, not asserted. The artifact that says a property holds must be produced mechanically and be reproducible by a third party who does not trust the vendor.
- The trusted base is small and nameable. Whatever enforces the guarantee has to be short enough to be reviewed, because a verifier nobody can audit is a vendor promise with better typography.