A runtime artefact trust gap is the difference between trusting reviewed source code and trusting the generated files that actually run. It appears when build outputs, caches, or intermediates can be changed after approval and before execution, especially in automated pipelines.
Expanded Definition
A runtime artefact trust gap is not a flaw in source review itself. It is the trust break that emerges when the artefact that was approved is not the same artefact that is later executed. In modern delivery pipelines, that can involve compiled binaries, container images, packaged scripts, cached dependencies, or generated policy files. The risk is strongest where build steps are automated, ephemeral, or distributed across multiple systems, because approval may occur before the final runtime object is assembled.
This concept sits at the intersection of software supply chain security, pipeline integrity, and operational trust. It is closely related to provenance and change control, but it is narrower than general supply chain risk because it focuses on the moment trust transfers from reviewed inputs to executable outputs. Standards do not yet use one universal label for this exact gap, so usage in the industry is still evolving. NIST guidance on control integrity and configuration management, including the NIST SP 800-53 Rev 5 Security and Privacy Controls, provides the closest formal control language.
The most common misapplication is assuming a code review or signed commit automatically proves the runtime artefact is trustworthy, which occurs when build outputs can be regenerated, replaced, or altered after approval.
Examples and Use Cases
Implementing runtime artefact trust checks rigorously often introduces release friction, requiring organisations to weigh delivery speed against stronger assurance that what runs is what was approved.
- A CI pipeline compiles source code, but an unprotected build cache injects a modified library into the final package after security review.
- A container image is scanned before publishing, yet the registry tag is later repointed to a different image digest that was never reviewed.
- An agentic AI workflow generates a script or policy file at runtime, and the generated artefact executes with more privilege than the reviewed template intended.
- A deployment system signs the source repository commit, but the artefact deployed into production was rebuilt from a different dependency graph.
- Infrastructure-as-code templates pass approval, but intermediate rendered files are altered before execution in an automated release stage.
For teams aligning pipeline controls to formal guidance, runtime artefact integrity maps well to change control, configuration baselining, and protection of system components under NIST control families. In practice, the question is not only whether code was reviewed, but whether the executed object can be cryptographically tied to that review.
Why It Matters for Security Teams
Security teams care about this gap because it undermines the assumption that approval, scanning, and testing still apply at execution time. If artefacts can drift between build and run, then the organisation may believe it is deploying a verified system while actually running something different. That creates exposure across vulnerability management, incident response, and compliance evidence, especially when audit trails capture source-level approval but not runtime provenance.
This is also increasingly relevant to NHI and agentic AI deployments. An AI agent may be authorised to create or launch artefacts, but if those artefacts are mutable after review, the agent can unintentionally or maliciously expand the execution surface. The same issue affects secret-bearing deployment jobs, where a trusted pipeline identity can be used to swap artefacts without changing the reviewed source.
Practitioners should treat the runtime boundary as a separate trust decision and insist on traceability from source to build output to execution target. Organisations typically encounter the consequences only after an unexpected production change or compromise is investigated, at which point runtime artefact trust becomes operationally unavoidable to address.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and CSA MAESTRO address the attack and risk surface, while NIST CSF 2.0, NIST SP 800-53 Rev 5 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.DS-6 | Protects integrity of software and information at rest and in transit. |
| NIST SP 800-53 Rev 5 | CM-3 | Configuration change control applies when artefacts can change after approval. |
| OWASP Non-Human Identity Top 10 | NHI guidance highlights risks when automation identities can alter artefacts. | |
| NIST AI RMF | MAP | AI RMF addresses provenance and governance for AI-generated outputs. |
| CSA MAESTRO | Agentic AI controls cover tool use and output integrity across workflow stages. |
Constrain agent actions so generated runtime artefacts must be attested and approved.
