Who is accountable when a release ships with incomplete software supply chain evidence?

Accountability at the point of release, not just at the point of build

Incomplete software supply chain evidence is not a paperwork problem; it is an accountability problem. When a release ships without a credible SBOM, PBOM, or exception trail, the organisation may still deploy the software, but it loses a defensible record of what was approved, what was known, and who accepted the residual risk. That matters for auditability, incident response, and product governance. The release owner, security engineering, and risk approvers all need a defined role in that chain, otherwise evidence gaps get normalised as “operational drift.”

For release governance, the real question is whether evidence is treated as a gate or an afterthought. If the evidence is incomplete, the release decision is also incomplete, because the approval lacks the artefacts needed to justify due diligence or to trace downstream liability. NIST’s control structure around system and information integrity, configuration management, and auditability is useful here because it frames evidence as part of controlled change, not a side document. NIST SP 800-53 Rev 5 Security and Privacy Controls

In practice, many security teams discover missing supply chain evidence only after a release has already been promoted and the approval trail has to be reconstructed under pressure.

How release evidence, ownership, and exception handling fit together

A sound release process separates three duties. First, the engineering or build function produces the evidence: SBOM content, component provenance, signing, and related artefacts that show what was assembled. Second, the security or platform function validates that the evidence is complete enough to meet policy. Third, the product or risk owner makes the acceptance decision when the evidence is incomplete but the business still wants to ship.

That separation matters because incomplete evidence can arise in different ways. Sometimes the build pipeline failed to emit the artefact. Sometimes the artefact exists but does not cover all dependencies, generated assets, or transitive components. Sometimes the evidence is present but not trusted because it was generated outside the controlled pipeline. Each case has a different ownership path and a different remediation path.

• SBOM evidence answers what was included in the release.
• PBOM evidence answers how the release was built and packaged.
• Exception approval answers why the release was allowed despite a gap.

The accountability model should therefore tie evidence generation to the pipeline owner, evidence validation to the security or governance function, and risk acceptance to the named business owner. That is the only way to preserve traceability when a supplier, tooling failure, or late-stage change introduces uncertainty. If the organisation cannot point to a named approver and a dated exception, the release was not truly governed, even if it was technically deployed. Where the release chain includes outsourced build steps or shared platforms, the control also has to cover handoffs, because evidence often fails at the boundary between teams rather than inside a single tool.

OWASP Non-Human Identity Top 10 is also relevant when the evidence pipeline depends on service accounts, automation tokens, or CI identities that can silently weaken provenance if their scope, rotation, or ownership is unclear.

This guidance breaks down when evidence is assembled from untrusted ad hoc exports rather than from the governed release path, because then the artefacts may look complete without actually being reliable.

Where the accountability model gets messy in real programmes

Tighter evidence controls often increase release friction, so organisations have to balance speed against proof quality.

The hardest edge case is not a total absence of evidence, but partial evidence that is “good enough” for one team and not good enough for another. For example, a release may have a software inventory but no provenance chain, or a provenance record but no signed exception for a known vulnerable dependency. Guidance varies here, but the common practitioner view is that any unresolved gap in the approved evidence set should be treated as a formal exception, not as an informal note in a ticket.

Another common wrinkle is shared accountability across internal and third-party delivery. If a supplier produces the build artefacts but the consuming organisation approves the release, the downstream owner still carries the risk acceptance burden. That is why accountability needs to be explicit in contracts, release gates, and evidence retention requirements. Otherwise, responsibility gets blurred between procurement, engineering, and security, and nobody can later explain why the organisation trusted the release.

There is also a practical distinction between “evidence missing” and “evidence unavailable.” Missing evidence usually implies a control failure. Unavailable evidence may point to retention, access, or trust problems that need a different fix. In both cases, the organisation should be able to answer the same question: who had authority to let the release proceed anyway? In many programmes, that answer only becomes visible after an incident, a customer challenge, or a compliance review has already exposed the weak point.

Practitioner Guidance

What to prioritise: Define the release gate first, then define the exception path. If the organisation cannot say which artefacts are mandatory before approval, accountability will drift to whoever is loudest at go-live rather than to the named risk owner.

What to verify: Check that each release has a traceable owner for evidence generation, evidence review, and exception approval. The key test is whether a third party could reconstruct who accepted the gap and on what basis, using retained records rather than oral history.

Common mistake: Treating SBOM or PBOM gaps as a documentation cleanup task after deployment. That shortcut usually converts a controllable governance issue into a delayed risk dispute, especially when a vulnerability later needs to be traced through the shipped release.

Practitioner takeaway: Accountability is strongest when evidence failure is handled as a governed decision with a named owner and a retained rationale, not as a temporary inconvenience that someone will tidy up later.

Related resources from NHI Mgmt Group

• What breaks when software supply chain risk is managed only after release?
• Who is accountable when stolen software supply chain credentials are used to publish malicious code?
• Who is accountable when AI review and release evidence is incomplete?
• Why do staged publishing and pre-release review matter for software supply chain security?