Your SSDF assessment finds every PO.5 secure-environment task sitting with a CI vendor nobody owns - what do you do?

## What the finding actually says A gap assessment that returns 'PO.5: delegated to the CI vendor' and stops has found something more interesting than a control weakness. The controls may well be excellent - a serious managed build provider very likely runs a tighter environment than the company would run itself. The defect is that **no one inside the organisation owns the relationship**: nobody reviews what the vendor claims, nobody is told when it changes, nobody renews anything, and nobody can produce evidence when a customer or an assessor asks. An unowned dependency is a decision that was never made. The distinction to hold on to: **operation can be delegated; the attested outcome cannot.** When you sign a statement that your development environments are secured, you are answering for the whole outcome regardless of whose hardware it runs on. 'Our vendor does that' is not an answer to an attestation; it is a description of where the evidence has to come from. ## Working the finding **1. Name an owner first.** Before any technical work, someone accountable is assigned to the vendor relationship - typically the platform or build engineering lead, with procurement and security as stakeholders. This single step converts a blank into a tracked item, and it is the part organisations skip. **2. Split PO.5 into inherited and retained.** Every managed platform has a boundary. Roughly: the vendor owns the environment's isolation, patching, tenancy separation and physical and operational security; you own what you configure inside it - which identities can trigger a build, what those identities can reach, what credentials are available to a job, and who can change the build definition. Almost every real gap in this pattern lives on *your* side of that line, and it is invisible while the whole practice is written off as 'the vendor's'. Write the boundary down; it is the artifact that makes the rest of the assessment possible. **3. Collect evidence for the inherited half.** The vendor's own security documentation, independent audit reports, published attestations and contractual security commitments. Map each to the PO.5 tasks it actually covers and mark honestly where nothing covers a task. A vendor claim you have not read is not evidence. **4. Record what is left.** Every unmatched task becomes one of: a control you bring in-house, a commitment you negotiate at renewal, or an explicitly accepted risk with a named owner and a review date. What it must never become is a blank cell, because a blank is indistinguishable from an oversight, and next year nobody will remember which it was. ## The organisational layer This is where the question stops being technical. - **Nobody funds it.** Vendor security review is unglamorous work that shows up on no roadmap. If it is not somebody's named responsibility with time attached, it will not happen, and the finding will reappear verbatim next year. - **Procurement is where the leverage is.** Evidence commitments, notification-on-change and audit rights are cheap to obtain at contract signature and nearly impossible to obtain afterwards. If the relationship is already unowned, renewal is the one moment when it can be fixed. - **Concentration risk becomes visible.** Once someone owns the relationship, the question 'what happens if this vendor is unavailable, or breached, or changes its terms' finally has an addressee. For a payments platform that is a business-continuity question, not just a security one. - **Say what you can prove.** The pressure in these situations is to answer the questionnaire green because the vendor is reputable. Reputation is not evidence. A supplier who says 'this task is inherited from our build provider, here is their report, and these two sub-tasks are ours and currently unevidenced' is more credible than one claiming uniform green, and materially safer for whoever signs. ## What not to do Do not mark PO.5 **not applicable**. Not applicable means the task genuinely does not pertain to your software; a build environment you use every day always pertains. Do not assume the vendor's attestation covers your configuration - it covers their platform, and it explicitly does not cover what you set up inside it. And do not let the finding turn into a project to bring the build platform in-house, which is usually the most expensive possible answer to a documentation-and-ownership problem. The specific technical hardening of a build runner is a separate discussion with its own answers; what the SSDF assessment is asking here is narrower and harder to dodge - who in this company can show that it is done.