A base image is the starting container image used in a Dockerfile or deployment definition. It brings in an operating system layer and bundled software that can carry vulnerabilities, configuration weaknesses, or outdated packages into every derived container unless the image is reviewed and maintained carefully.
Expanded Definition
A base image is the foundation layer in a container build, typically defined in a Dockerfile and inherited by every image built from it. In NHI and agentic workloads, it matters because the image often ships with default packages, OS libraries, runtime components, and configuration choices that become part of the trust boundary for every service account, API client, or AI agent that runs inside the container.
Definitions vary across vendors on where “base image governance” begins, but the practical boundary is clear: once a team inherits a base image, it inherits the image’s patch status, package provenance, and build hardening posture. That makes base images closely related to image provenance, software supply chain assurance, and secure build pipelines, but not identical to them. Guidance from the NIST Cybersecurity Framework 2.0 reinforces the need to manage technology assets and reduce exposure across the environment, which includes container layers that are reused at scale.
The most common misapplication is treating a base image as a disposable developer convenience, which occurs when teams promote unreviewed images into production without patching, pinning, or provenance checks.
Examples and Use Cases
Implementing base image controls rigorously often introduces release friction, requiring organisations to weigh build speed against the cost of validating every inherited dependency and rebuilding when the upstream image changes.
- A platform team standardises on a hardened language runtime image so application teams do not each maintain their own operating system packages.
- A security team blocks deployments that pull from unapproved registries, reducing the chance that a compromised image becomes the starting point for production services.
- An ML engineering group uses a pinned base image for model-serving containers so GPU drivers, Python libraries, and runtime tools remain predictable across environments.
- A CI/CD pipeline scans the base image before merge, then again after rebuild, because upstream patches can change the risk profile of every derived container.
- Operators use supply-chain guidance from the Ultimate Guide to NHIs alongside NIST Cybersecurity Framework 2.0 to treat container images as governed assets, not one-time build artifacts.
In practice, the term also applies when teams choose between minimal images and fuller distributions. Smaller images reduce attack surface, but they can make troubleshooting, observability, and compatibility harder for platform engineers.
Why It Matters in NHI Security
Base images matter in NHI security because non-human workloads often execute with broad tool access, embedded secrets, or service credentials, and a vulnerable shared image can compromise many identities at once. NHIMG research shows that 96% of organisations store secrets outside of secrets managers in vulnerable locations, including code, config files, and CI/CD tools, which means container build paths frequently intersect with secret exposure and runtime misuse. When a base image is outdated or over-permissioned, every derived container can inherit the same weak foundation, multiplying the blast radius across APIs, automation jobs, and AI agents.
A disciplined base image program supports image signing, patch cadence, dependency review, and provenance verification. It also helps teams enforce consistency when service accounts, tokens, and certificates are injected into containerised workflows that need tight operational controls. The Ultimate Guide to NHIs documents the scale of this problem across enterprise environments, and the lesson is that identity risk and image risk often converge inside the same pipeline. Organisations typically encounter base image risk only after a compromised container or secret leak, at which point the image 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 OWASP Agentic AI Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST Zero Trust (SP 800-207) and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 | Base images shape inherited exposure for NHI workloads and containerised service identities. |
| NIST CSF 2.0 | PR.DS | Base image integrity and patching support data and software protection across the stack. |
| NIST Zero Trust (SP 800-207) | Zero Trust depends on reducing implicit trust in inherited software components. | |
| NIST AI RMF | AI systems inherit risk from their container base images and bundled dependencies. | |
| OWASP Agentic AI Top 10 | Agentic workloads often run in containers whose base images determine execution risk. |
Protect container image integrity with scanning, signing, and rebuild controls throughout the lifecycle.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 28, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
