What should security teams do when a trusted build might contain unverified code?

What a Security Team Should Do First

When a trusted build may contain unverified code, the first move is to stop treating the trust label as sufficient and reconstruct the build evidence. Security teams should determine exactly what changed, which inputs were signed off, and whether the artefact still matches the approved source, pipeline state, and release decision. The question is not whether the build was once trusted, but whether its provenance is still defensible.

That means reviewing the build record, dependency inputs, compilation steps, and any late-stage injection points where unverified code could enter without immediate visibility. If the artefact cannot be traced back to a controlled source and a repeatable process, the trust claim is operationally weaker than the evidence trail.

For build provenance and integrity verification, SLSA is the clearest external reference point because it focuses on whether the artefact was produced through a verifiable supply-chain process rather than assumed safe because it is labelled trusted. In practice, this is the difference between accepting a release and being able to defend it.

Where Unverified Code Usually Enters the Release Path

Unverified code often enters through weak separation between reviewed and unreviewed inputs, dependency confusion, compromised build steps, or an approved pipeline that no longer reflects the code actually shipped. The failure is rarely only at the final signing step. More often, the break occurs earlier, where review, automation, and approval boundaries are too coarse to show exactly what was introduced.

A useful way to think about the problem is that the release process can still look healthy while the artefact has already drifted from what was examined. That is why teams need to inspect source lineage, dependency resolution, generated files, and any automation that can alter the output after approval.

OWASP SAMM is relevant here because the issue is not just a bad build event, it is a maturity gap in how organisations build security into software delivery. Where the release path is opaque, teams should treat that opacity as a process defect, not a one-off exception.

For a deeper view of code and runtime container risk, NIST SP 800-190 Container Security helps teams reason about how images, registries, and runtime assumptions can mask the arrival of unreviewed content.

How to Contain the Release Without Breaking Governance

Containment should focus on restoring certainty before making another release decision. That usually means freezing the suspect artefact, comparing it to the last known-good source state, checking whether the build was reproducible, and identifying every approval that relied on incomplete evidence. If the team cannot explain where the code came from, the safe assumption is that the release decision was premature.

Security teams should also preserve the build metadata, logs, dependency manifests, attestations, and sign-off records so the investigation can distinguish between an authentic change and an integrity failure. The goal is not to prove maliciousness immediately, but to separate approved material from unapproved material fast enough to prevent further propagation.

NIST SP 800-53 Rev 5 Security and Privacy Controls supports this containment mindset because auditability, configuration control, and system integrity are the control properties that make a release defensible after the fact.

Risk and Threat Considerations

When unverified code can ride inside a trusted build, the core risk is false assurance: teams may deploy and extend trust before they have proven integrity. That creates exposure not only to accidental process failure, but also to supply-chain compromise, malicious code insertion, and hidden persistence inside a release path that operators assume is clean.

Failure mechanism: The build or release pipeline accepts an artefact as trusted even though a code path, dependency, generated file, or post-review step introduced content that was never fully validated.

Impact: A compromised or partially unverified release can propagate into production with the organisation’s own approval stamp, widening blast radius, weakening incident response, and delaying detection because the trust label suppresses scrutiny.

Practitioner Guidance

What to verify: Confirm the exact source commit, dependency versions, build environment, and approval trail that produced the artefact. If any of those are missing or inconsistent, treat the build as suspect rather than merely incomplete.

Decision rule: If the artefact cannot be traced to evidence you would be willing to defend in an incident review, do not rely on the trust label for deployment, exception handling, or downstream promotion.

What good looks like: A trustworthy release has a clear lineage from source to artefact, a reproducible or explainable build path, and an approval record that matches the actual content shipped.

Practitioner takeaway: The right response is to validate provenance before preserving trust, because once unverified code enters the build path, the label is no longer the control, the evidence is.

Related resources from NHI Mgmt Group

• Why are NHIs a critical concern for security teams?
• What steps should security teams take to prevent Shadow AI risks?
• Why is the abuse of NHIs a priority for security teams?
• What is the difference between SAST and DAST for security teams?