Treat the image as a maintenance risk, not a stable long-term control. Teams should verify whether the upstream repository still publishes security updates, then update the package list, rebuild the image, and redeploy. If a base image is no longer maintained, the safer response is to move to a supported image rather than delay remediation.
Why an Unpatched Base Image Becomes a Release Engineering Problem
A pinned base image only remains a useful control while its upstream maintainer still publishes fixes for known vulnerabilities. Once critical patches stop arriving, the pin no longer gives you stability in the security sense, because it freezes exposure as well as versioning. That changes the question from “can we keep this image unchanged?” to “how quickly can we replace it without breaking the build and deployment path?”
For containerised systems, the real risk is not simply that an image is old. It is that teams may keep shipping a trusted artifact after the package set inside it has become stale, which can preserve known flaws across many services and environments. The safest response is to treat the image as a dependency with a lifecycle, not as an immutable asset. Where container supply chain governance is mature, teams also track whether the image still fits their patch cadence and whether the upstream source is a reliable maintenance signal rather than a convenience choice. The OWASP Non-Human Identity Top 10 is relevant here only at the boundary where automation consumes the image, because the operational issue remains image maintenance first. In practice, many security teams discover the maintenance gap only after a vulnerability scan or production incident has already exposed how long the pin has been drifting.
What the Rebuild Decision Looks Like in Practice
The practical sequence starts with confirming whether the upstream image owner still supports the tag you pinned. If security fixes have stopped, there are only two defensible options: move to a supported image line, or accept a clearly time-bounded exception while the rebuild is scheduled. A pinned version should never be treated as a substitute for maintenance.
Teams should then decide whether the base image change is purely a patch refresh or whether it also requires package updates, runtime changes, or application compatibility testing. A clean rebuild is preferable because it pulls in the latest available fixes from the maintained source, but rebuilds still need verification. That means comparing the resulting package list, scanning for residual vulnerabilities, and confirming that the deployment artifact in CI/CD is the one actually running in production.
- Check whether the source image still receives security updates for the tag or release line you use.
- Rebuild from a maintained base rather than layering more fixes onto an abandoned image.
- Rescan the rebuilt image before promotion, because patch availability does not guarantee a clean result.
- Redeploy through the normal release path so the patched image becomes the new controlled baseline.
Where this guidance breaks down is in workloads that depend on legacy packages or runtime behaviour that no supported image can match without code change, because then the issue is not just patching but technical compatibility.
When a Pinned Image Is Still Acceptable, and When It Is Not
Tighter image pinning improves repeatability, but it also increases maintenance burden, so organisations have to balance build determinism against patch freshness.
There is a genuine operational difference between pinning to preserve reproducibility and pinning to avoid change. The former is acceptable when the image is still actively maintained and the team has a predictable rebuild process. The latter becomes risky when the pin is used as a shortcut to defer upgrades indefinitely. Industry practice is fairly consistent on this point, even if implementation details differ: a pinned image is only trustworthy when there is an active plan to refresh it and prove that the refreshed version still behaves correctly.
Teams should also be careful not to confuse “no urgent application breakage” with “safe to keep.” A base image can appear stable for months while silently accumulating known exposure, especially if the application code changes infrequently and nobody reviews the upstream maintenance status. That is why support status matters as much as vulnerability count. The better the dependency governance, the less likely a team is to inherit a long-lived, unmaintained image line by accident.
For systems with strict change control, the key exception rule is simple: if the image cannot receive fixes and there is no supported path forward, it should be treated as a controlled exception with a removal date, not as a permanent baseline.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK address the attack and risk surface, while CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | 7 — Continuous Vulnerability Management | Outdated base images create unmanaged vulnerability exposure across builds. |
| 4 — Secure Configuration of Enterprise Assets and Software | Pinned images must remain supported and consistently rebuilt from trusted sources. | |
| Recommendation — Rebuild and rescan the image after each upstream security release. Maintain only supported base images in your approved build pipeline. | ||
| NIST CSF 2.0 | PR.IP-12 — Vulnerability management plan | A no-longer-patched image requires a defined remediation and replacement process. |
| DE.CM-8 — Vulnerability scans | Rescanning rebuilt images verifies that critical fixes were actually incorporated. | |
| Recommendation — Apply PR.IP-12 to retire unsupported images on a tracked remediation timeline. Use DE.CM-8 to validate patched images before promotion. | ||
| MITRE ATT&CK | T1611 — Escape to Host | Stale base images can preserve weaknesses that support post-compromise exploitation paths. |
| Recommendation — Hunt for exploitable container weaknesses that could aid host escape. | ||
Practitioner Guidance
What to prioritise: Replace the maintenance assumption before you spend time tuning the scan output. If the upstream image is out of support, remediation work should centre on migration to a maintained base, not on defending the old one.
What to verify: Confirm that the rebuilt image really comes from a supported upstream and that the package set changed as intended. A rebuild that preserves the same vulnerable lineage is not a fix, even if the tag name changes.
Decision rule: If the image is no longer receiving critical fixes, treat every deployment of that base as a time-limited exception until the supported replacement is live. If the application cannot move cleanly, escalate the compatibility issue rather than silently accepting exposure.
Practitioner takeaway: The important judgment is not whether the image is pinned, but whether the pin is anchored to an actively maintained security baseline; once that baseline disappears, version stability stops being a control and becomes a liability.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 10, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
