Container inspection to RMF controls for CI/CD compliance

At a glance

What this is: This is a guide to mapping container inspection into DoW RMF and NIST 800-53 controls, with the key finding that point-in-time scanning is inadequate for ephemeral containers.

Why it matters: It matters because IAM, NHI, and platform security teams need controls that govern automated build and runtime paths, not just static images or registry records.

Context

Container compliance fails when teams assume a workload can be scanned once and then left in place. Ephemeral containers are created, replaced, and discarded faster than traditional control cycles, so evidence has to move into the build, admission, and policy layers rather than depend on post-deployment review.

The stronger governance problem is not whether controls exist, but whether they can be proven continuously in an automated pipeline. That is where container security intersects with NHI governance, because build systems, registries, and CI/CD runners frequently carry the secrets and permissions that make container delivery possible.

Key questions

Q: What breaks when security teams rely on point-in-time container scans alone?

A: Point-in-time scans create false confidence because the environment changes faster than the scan cycle. New pods, configuration drift, temporary network rules, and workload changes can make yesterday’s clean report irrelevant today. Teams then miss active risk while spending cycles on stale findings. Continuous runtime context is what keeps prioritisation aligned with the current attack surface.

Q: Why do CI/CD pipelines create secret governance risk?

A: Because they combine stored credentials, automated execution, and broad operational access in one place. If a pipeline can read a secret and use it to perform a privileged action, the secret becomes a standing access path. That risk grows when variables, logs, artifacts, or runner environments expose the credential beyond the intended job.

Q: How do organisations prove container controls for RMF and NIST 800-53?

A: They prove them by mapping each control to the layer that actually enforces it. Some requirements come from platform functions such as access control and logging, while others come from policy checks that inspect the image itself. The evidence set should show both operational governance and artefact-level enforcement, not one or the other.

Q: Should teams treat container policy as a runtime issue or a build issue?

A: For most compliance objectives, it should be treated first as a build issue. Runtime controls matter, but they cannot correct a non-compliant artefact that has already been promoted. The stronger pattern is to stop bad images early, then use runtime monitoring as a second line of defence rather than the primary compliance mechanism.

Technical breakdown

Why point-in-time scanning fails for ephemeral containers

Point-in-time scanning assumes the asset remains stable long enough for a finding to matter. Containers do not behave that way. They are often rebuilt, redeployed, and terminated before a manual compliance cycle can finish, which means remediation must happen upstream in the pipeline. Policy-as-code is the shift from detective verification to preventive control, where admission rules and build checks decide whether an image can progress. In practice, this turns compliance into a gating function instead of a retrospective report.

Practical implication: Use build-time policy enforcement to stop non-compliant images before they reach a registry or cluster.

How control mapping works across platform features and policy rules

The article separates platform capabilities from policy logic. Platform features such as role-based access control, event logging, and system inventory support operational governance, while policy checks inspect image contents for things like prohibited software, unencrypted secrets, and provenance failures. That distinction matters because a control objective may be met partly by the platform and partly by the inspection rules. For RMF evidence, teams need both layers: proof that access and logging exist, and proof that the image itself satisfies the policy conditions tied to the control.

Practical implication: Map each control to the layer that actually enforces it, rather than treating the container platform as a single control surface.

Why secrets, provenance, and least privilege belong in the same inspection path

Secrets leakage, image provenance, and container privilege are often treated as separate topics, but the attack surface connects them. A container that carries unencrypted secrets, pulls from an untrusted build chain, or runs with excessive privileges creates a direct path from build compromise to runtime misuse. The article’s control mapping reflects that relationship by tying secret checks, provenance validation, and rootless execution to governance outcomes. For containerised environments, these are not optional hardening steps; they are the conditions that make automated compliance defensible. See the Secrets Management Guide.

Practical implication: Inspect credentials, provenance, and privilege together so the build pipeline cannot certify a container that is unsafe to run.

Threat narrative

Attacker objective: The attacker wants to turn the container supply path into a trusted channel for running unauthorised or privileged code.

1. Entry occurs through the software delivery path, where insecure build artefacts or exposed CI/CD components can introduce untrusted container content.
2. Credential access or abuse follows when secrets embedded in images, configs, or pipeline tooling are available to a build or deployment actor.
3. Escalation happens when an image with weak provenance or excessive privilege is promoted into an environment that trusts the pipeline by default.
4. Impact is unauthorised container execution, policy bypass, or downstream compromise of the runtime environment and associated workloads.

Breaches seen in the wild

• reviewdog Action compromise 2025: A stolen maintainer token poisoned reviewdog/action-setup, leaking CI secrets including the tj-actions bot token used in the next attack.
• CI/CD pipeline exploitation case study: Credentials in an exposed .git/config let a researcher edit a Bitbucket pipeline so it planted their SSH key on the server. No victim was named.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Container compliance has moved from image review to pipeline governance. A static scan can prove only that an image looked acceptable at one point in time. In Kubernetes and CI/CD environments, the decisive control is whether policy is enforced before the artefact is allowed to move forward. That changes the governance question from “was it scanned?” to “was it prevented from progressing when it violated policy?” Practitioners should treat build-time policy enforcement as the control plane for compliance.

Secrets in the delivery path are the governance gap this article exposes. The most important failure mode is not just vulnerable software, but leaked credentials inside code, configs, or CI/CD tooling that the platform then treats as normal inputs. That is an identity problem as much as a container problem, because build runners and pipeline tokens act like non-human identities with real authority. Static vs dynamic secrets becomes relevant here: long-lived credentials inside pipelines undermine any claim of continuous control.

Policy-as-code is only credible when it maps to specific control objectives. The article is strongest when it distinguishes access control, logging, inventory, configuration management, and provenance as separate evidence streams rather than collapsing them into a single “compliance” label. That is how container security avoids becoming a checkbox exercise. The practitioner takeaway is simple: map each policy check to the control outcome it substantiates, then retain the evidence chain from build to deployment.

Container provenance is now part of supply-chain trust, not just software quality. When image provenance is validated alongside secret scanning and least-privilege execution, the organisation is really governing whether an artefact can be trusted at all. That makes the CI/CD system itself a privileged environment that must be inventoried, logged, and constrained like any other high-trust platform. Security teams should fold container inspection into the broader supply-chain assurance model, not leave it isolated in DevOps.

From our research library:

• 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, according to the Ultimate Guide to NHIs.
• 59% of compromised machines in a major 2025 supply chain attack were CI/CD runners rather than personal workstations, according to the State of Secrets Sprawl 2026.
• Read next: Secrets Management Guide

What this signals

Policy-as-code is becoming the governing concept for container compliance. The practical shift is from verifying images after the fact to enforcing acceptable conditions before promotion. For programme owners, that means evidence generation has to be built into the delivery path, with policy checks and approval gates treated as part of the control design rather than a separate audit activity.

Secrets sprawl inside CI/CD remains a direct control weakness. When credentials live in code, configs, and pipeline tooling, the container platform inherits a non-human identity problem that traditional scanning alone cannot solve. Organisations should align build security with identity governance so the pipeline cannot silently carry long-lived authority across environments.

For practitioners

• Define build-time policy gates for container promotion Block images that violate policy before they are pushed to a production registry or deployed to a cluster, and require an evidence trail for each failed gate.
• Separate platform controls from image-content controls Document which requirements are satisfied by RBAC, logging, and inventory, and which are enforced by policy rules that inspect image contents.
• Search for secrets in images and pipeline inputs Inspect code, configuration files, CI/CD tools, and built artefacts for embedded credentials, then revoke or replace any secrets that appear in those paths.
• Tie container evidence to RMF control objectives Maintain mappings from each automated check to the control it substantiates so auditors can trace how container inspection supports the ATO evidence set.

Key takeaways

• Container compliance fails when teams rely on static scanning for workloads that are created and destroyed continuously.
• The article ties compliance evidence to concrete control families, including access, logging, inventory, secrets handling, provenance, and least privilege.
• For practitioners, the priority is to enforce policy before promotion and to treat CI/CD secrets as part of the identity governance surface.

Related NHI Mgmt Group resources: Guide to the Secret Sprawl Challenge · Ultimate Guide to NHIs: Static vs Dynamic Secrets · Secrets Management Guide · reviewdog Action compromise 2025

Key terms

• Policy as Code: Policy as code stores authorization logic in version control and evaluates it through testable, reviewable rules. For agent governance, it makes runtime decisions reproducible and measurable, which is critical when actions can be triggered by untrusted content and executed at machine speed.
• Ephemeral Container: An ephemeral container is a short-lived container that may start and stop in seconds. Because it can disappear before traditional agents report back, it creates a visibility problem for security teams. Detecting and assessing these workloads usually requires out-of-band or storage-level inspection.
• Container provenance: Container provenance is the evidence that shows where an image came from, who built it, and which dependencies and registry sources were involved. It is essential for trust decisions because it allows security teams to distinguish a known release from an opaque artifact.
• Build-Time Gate: A build-time gate is an automated checkpoint that prevents an artefact from advancing unless it meets defined security or compliance conditions. In container environments, it shifts control enforcement upstream so non-compliant images are stopped before they reach a registry or cluster.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, secrets management, and workload identity. It helps security and identity teams connect pipeline trust, credential lifecycle, and governance evidence.