The board asks which supply chain entry points your pipeline is open to today — how do you answer with evidence?

## Why the usual readout fails Asked "are we exposed to supply chain attacks", most organisations answer with activity: tools purchased, scans running, a maturity score, a percentage of repositories enrolled. None of that answers the question, because every one of the well-known compromises would have sailed past a pipeline that scored well on all of it. The readout that works uses the *entry points* as its structure, because those are the things an attacker actually chooses between. ## The agenda: four doors **1. Someone modifies the build.** The threat is an artifact that does not correspond to the source anyone reviewed. Evidence that it is shut is not "the build servers are patched"; it is whether an artifact can be tied to a specific source revision and builder, whether a human or a job token can alter a release build without leaving a trace, and how many people or systems can reach the build environment at all. Most organisations discover here that their honest state is "open", because build systems accumulate privileged access for good reasons and nobody has ever inventoried it. **2. A dependency changes hands.** The threat is that the code keeps its name while the person behind it changes — voluntarily or through a stolen account. Evidence is whether anything in your intake would notice: do new transitive dependencies enter builds without review, would a change of maintainer or a sudden first release after long dormancy raise anything, and how quickly does a brand-new version reach production. "We pin versions" is partial evidence; "we pin and nothing updates a pin without a human" is stronger. **3. A pipeline downloads and executes something.** The threat is that a URL your CI trusts serves different content tomorrow. Evidence is a concrete count: how many pipeline steps fetch a script, a binary or an action and execute it without verifying it against a digest, and what credentials are in scope when they run. This one is usually the cheapest to close and the most embarrassing to enumerate, because the count is never zero and nobody has looked. **4. Your own publishing identity.** You are also somebody's upstream, and the same account takeover that hits a maintainer hits you. Evidence is who can publish a release, what authentication protects that, whether a single compromised credential is sufficient, and whether consumers could distinguish a genuine release from a forged one. ## The three states, and why convention counts as open For each door, force the answer into one of three states: - **Closed and enforced** — something mechanical prevents it, and you can point at what. - **Closed by convention** — the team does the right thing, and nothing would stop them doing otherwise. - **Open** — nobody is doing the right thing, or nobody knows. The second state is where readouts go wrong, because it feels like a pass and behaves like a fail. A convention survives exactly until someone is under deadline pressure, and it produces no evidence for a customer or an auditor. Report it as open with a note. Similarly, "we have never had an incident here" is not evidence; it is absence of detection, and in this domain the detection is usually external anyway. ## Cost, and the sequencing argument A board hears a list of gaps as a list of invoices, so the readout must carry cost and sequence or it will be sent away for prioritisation. The shape that lands: - Doors that close in weeks with existing people — enumerating and pinning what pipelines execute, narrowing what credentials are visible to build steps, requiring a human on dependency updates in the highest-blast-radius services. - Doors that close over quarters with real investment — isolating and hardening build environments, producing and verifying evidence about how artifacts were built, restructuring who can publish. Then say plainly which doors you propose to leave open for now and why, in terms of blast radius rather than likelihood. Nobody can estimate the probability of a build-system compromise honestly; everybody can estimate what an attacker would reach if one happened. ## The tone that survives the follow-up question Two failure modes book-end this conversation. Over-claiming ("we are protected against supply chain attacks") does not survive the first question a competent director asks, and it destroys your credibility for the next request. Catastrophising ("we are wide open, everything is at risk") gets funded once and ignored afterwards. The credible register is specific and bounded: here are four doors, here is the evidence for each, two are open, one costs a quarter of an engineer, one costs a team for two quarters, and here is what I recommend we accept in the meantime and revisit. One more thing worth stating explicitly to a board: none of this is a claim that an incident becomes impossible. What closing these doors buys is that a compromise leaves evidence, is bounded in scope, and can be answered to customers with records rather than assurances.