They need both, but provenance should come first when the source of the artifact is uncertain, while runtime detection becomes decisive once workloads are deployed. Provenance tells you who created the risk, and runtime telemetry tells you whether it has become operationally relevant.
Why container teams should start with provenance
Provenance is the better first move when you cannot trust the source of a container image, layer, base image, or build pipeline. It answers the earlier question: can this artifact be traced to a known builder, reviewed supply chain, and repeatable process? That matters before runtime because a compromised image can arrive fully weaponised, with secrets, backdoors, or malicious dependencies already embedded.
For container supply chains, provenance is not abstract paperwork. It is the difference between an artifact that can be verified at the point of intake and one that enters the environment on trust alone. Standards and guidance such as SLSA and NIST SP 800-190 Container Security both treat image integrity, registry trust, and build controls as upstream defenses, because they reduce the chance that a bad artifact ever reaches a runtime sensor.
That sequencing also explains why provenance and runtime detection solve different problems. Provenance is strongest when you need to decide whether an artifact should be deployed at all. Runtime detection is strongest when you need to decide whether a deployed workload is behaving safely, has been tampered with, or is showing signs of active abuse. In practice, one is an intake control and the other is an operational control.
When runtime detection becomes the decisive control
Once a workload is running, telemetry becomes the control that can confirm whether the container is acting outside its expected boundaries. Runtime detection can reveal process injection, suspicious outbound connections, privilege escalation attempts, container escape activity, or access to files and sockets that should never be touched. At that point, provenance alone is no longer enough, because a validly built image can still be misused after deployment.
That is why runtime detection is especially important for long-lived services, internet-facing workloads, and environments where image trust is necessary but not sufficient. If the deployment pipeline is clean but the runtime environment is noisy, exposed, or poorly segmented, a good artifact can still become an incident. Detection gives teams the chance to contain the blast radius after the trust boundary has already been crossed.
Frameworks focused on defensive technique mapping, such as MITRE D3FEND, are useful here because they help teams think in terms of countermeasures against observable attacker behaviour, not just image pedigree. For teams building detection coverage, SANS Security Resources is a practical reference point for incident handling and detection engineering patterns.
How to decide the order in real container environments
The right sequence depends on what you are trying to reduce first: uncertainty or exposure. If you are onboarding new images, third-party packages, or externally supplied build outputs, provenance should come first because it determines whether the artifact is admissible. If the workload is already deployed and the question is whether it is being abused, runtime detection should get immediate operational priority.
In mature container programmes, the two controls should be layered, not treated as substitutes. Provenance reduces the chance of shipping a poisoned artifact. Runtime detection reduces the chance that an artifact, however introduced, can persist unnoticed. The strongest posture is to verify the artifact before deployment and continue observing it after deployment.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while SLSA, NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| SLSA | Supply Chain Levels for Software Artifacts | Build provenance directly governs whether a container artifact can be trusted before deployment. |
| Recommendation — Require verifiable build provenance and artifact integrity before promoting container images. | ||
| NIST SP 800-53 Rev 5 | SI-4 — System Monitoring | Runtime detection depends on monitoring deployed container behaviour for malicious or abnormal activity. |
| CM-5 — Access Restrictions for Change | Container image and deployment trust rely on restricting unauthorized changes to artifacts and pipelines. | |
| Recommendation — Instrument container workloads with continuous monitoring for suspicious execution and network behaviour. Restrict changes to approved container artifacts, build steps, and deployment paths. | ||
| MITRE ATT&CK | Enterprise Matrix | Runtime container abuse maps to adversary techniques like execution, credential access, and persistence. |
| Recommendation — Map suspicious container activity to ATT&CK techniques and tune detections for the relevant attack paths. | ||
| CIS Controls v8 | CIS-12 — Network Infrastructure Management | Container runtime exposure and segmentation shape how quickly abuse becomes operationally visible. |
| Recommendation — Harden container network exposure and segment workloads to reduce blast radius. | ||
Practitioner Guidance
What to prioritise: Prioritise provenance for intake decisions, especially for third-party images, unsigned artifacts, or builds that lack reproducible history. Prioritise runtime detection when the container is already in production, the workload has external reach, or you have reason to suspect an active compromise.
Decision rule: If you cannot explain where an image came from and who built it, treat provenance as the first gate. If you already trust the artifact source but cannot confidently observe execution behaviour, treat runtime telemetry as the first operational control.
What good looks like: Teams can block untrusted artifacts before deploy, then detect abnormal process, network, and privilege behaviour after deploy without relying on the same control for both jobs.
Practitioner takeaway: Provenance answers whether the container should enter the environment, while runtime detection answers whether it should stay there.
Related resources from NHI Mgmt Group
- Should teams prioritise Helm template review or runtime detection first?
- What do security teams get wrong about container runtime detection?
- How do identity teams decide whether runtime detection or posture management should come first?
- Should organisations prioritise runtime detection or pre-production controls first?