Why do pre-approved containers still need identity review?

Why This Matters for Security Teams

Pre-approved containers can still carry identities that are far more powerful, longer lived, or more broadly federated than the software package itself suggests. That matters because the container image is only one layer of trust. The runtime identity, secret injection path, and downstream access policy can all change after approval, which is why identity review remains a separate control. NIST’s NIST Cybersecurity Framework 2.0 reinforces that access and governance must be managed continuously, not only at build time.

NHIMG research on Ultimate Guide to NHIs shows that identity is the control plane behind many modern non-human workloads, while incident patterns in the 52 NHI Breaches Analysis show that exposed or over-permissioned credentials often become the real failure point, not the container artifact itself. Security teams that stop at image approval tend to miss secrets, service accounts, workload federation, and inherited cloud permissions that remain active long after deployment. In practice, many security teams encounter identity abuse only after an approved container has already been used to reach systems it was never supposed to touch.

How It Works in Practice

Identity review should follow the same container through the full lifecycle: build, deploy, and runtime. The question is not only whether the image is trusted, but whether the container is allowed to assume a workload identity, mount secrets, call APIs, or federate into cloud services. Current guidance suggests reviewing the effective identity rather than the package label, because a clean image can still inherit risky access through Kubernetes service accounts, IAM role bindings, secret volumes, or external identity federation.

A practical review usually covers four checks:

• What identity the container uses at runtime, including service accounts and workload tokens.
• Which secrets, certificates, or API keys are injected, and how long they remain valid.
• What permissions the workload inherits from its namespace, cluster, cloud account, or CI/CD pipeline.
• Whether access is bounded by just-in-time issuance, short TTLs, and revocation on completion.

This is where workload identity becomes the more useful primitive. Standards such as SPIFFE and policy systems that evaluate at request time help teams reason about what the workload is right now, not what it was when the image was signed. That distinction is especially important when a container image is reused across environments or attached to different roles in different clusters. NHIMG’s Top 10 NHI Issues highlights how credential sprawl and stale trust paths often survive otherwise strong image governance. These controls tend to break down in highly automated CI/CD environments because identity mappings are created and changed faster than manual review can keep pace.

Common Variations and Edge Cases

Tighter identity review often increases deployment friction, requiring organisations to balance release speed against the risk of hidden privilege. That tradeoff is real, especially where teams run ephemeral jobs, multi-tenant clusters, or cross-account automation. There is no universal standard for this yet, but best practice is evolving toward continuous identity checks for any container that can access secrets, invoke external APIs, or act on behalf of another system.

Edge cases deserve extra scrutiny. A pre-approved container may still be risky if it:

• Uses a shared service account across environments.
• Receives long-lived static secrets instead of short-lived tokens.
• Can exchange one identity for another through federation or impersonation.
• Runs in a privileged namespace with broader access than intended.

NHIMG’s JetBrains GitHub plugin token exposure and DeepSeek breach both underscore a recurring pattern: the container or application may look approved, but the identity material around it is what enables abuse. For that reason, identity review should be repeated whenever secrets, roles, federation rules, or runtime boundaries change, even if the image hash does not.

Related resources from NHI Mgmt Group

• When does a machine identity become a compliance problem?
• Why is it important to integrate identity and data governance?
• When does secret exposure become a broader identity risk?
• What is the difference between patching a vulnerability and reducing identity blast radius?