Curated images are usually the safer choice when workloads have legacy dependencies, unclear package requirements, or limited engineering capacity for continuous rebuilds. Scratch images can be effective, but only when the team can maintain the dependency graph and hardening effort over time.
When curated images are the better default
Curated images are the better choice when teams need a known-good starting point that reduces uncertainty around package selection, patch posture, and baseline hardening. They are especially useful where application teams are not image-build specialists and where the cost of revalidating every dependency in a bespoke image would slow delivery more than it would improve control.
That makes curated images a practical fit for inherited or legacy software, mixed estates, and platforms with repeated onboarding of similar workloads. The value is not that they are “more secure” in every case, but that they make security and supportability more predictable.
For containerised workloads, NIST’s NIST SP 800-190 Container Security is a useful reminder that image content is only one part of the control surface, because registries, orchestration, runtime configuration, and trust in the image lifecycle all matter.
When scratch images are justified
Scratch images make sense when the workload can genuinely run with only the files and libraries it needs, and when the team can keep the resulting image small, reproducible, and continuously rebuilt. They are strongest in tightly controlled services where the dependency graph is simple, the runtime is well understood, and build pipelines already enforce strong artifact discipline.
The trade-off is operational, not just technical. Scratch images reduce the amount of packaged software you ship, but they shift responsibility onto the team to prove that every required binary, certificate, CA bundle, and runtime dependency is present and maintained outside a distribution base. If that discipline weakens, the image becomes brittle rather than minimal.
In supply-chain terms, the closer your process is to a controlled build and release system, the more viable scratch becomes as a hardening choice. When reproducibility or provenance is weak, a curated base image is usually the safer operational default.
How to choose between them in practice
The decision usually turns on maintainability and blast radius. Choose curated images when the workload changes often, when multiple teams will operate the same pattern, or when the organisation needs a clearer patching and support model. Choose scratch when you have a narrow runtime, strong build automation, and enough engineering capacity to own the full lifecycle of the dependencies you omit from the base image.
A simple rule works well: if the security team or platform team cannot quickly explain how the image is rebuilt, scanned, and updated, scratch is probably too brittle for that workload. If the team can explain that lifecycle confidently and prove it in CI/CD, scratch can be a good fit for reducing attack surface.
Risk and Threat Considerations
Scratch images can create hidden risk when the “minimal” image masks missing dependency controls, stale libraries, or inconsistent rebuild practices. Curated images can also carry risk if they are accepted blindly, but they usually fail more visibly because the base layer is easier to inventory, scan, and update.
Failure mechanism: teams adopt scratch to reduce surface area, but without disciplined rebuilds and dependency tracking they lose visibility into what is actually running, making patching, provenance, and vulnerability management harder over time.
Impact: the result is brittle workloads, delayed remediation, and a false sense of hardening. In regulated or high-change environments, that can turn into operational outages or exposure to known library flaws that no one is reliably tracking.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | CM-2 — Baseline Configuration | Curated vs scratch images both depend on a controlled, repeatable software baseline. |
| SI-2 — Flaw Remediation | Image choice affects how reliably dependencies and package flaws can be remediated. | |
| SA-10 — Developer Configuration Management | Scratch images require stronger build discipline and dependency control to stay reproducible. | |
| Recommendation — Establish a managed image baseline and approve deviations before deployment. Patch and rebuild images on a defined cadence when dependencies change or flaws emerge. Control build inputs and preserve reproducible image construction across releases. | ||
| ISO/IEC 27001:2022 | A.8.9 — Configuration management | Image selection is a configuration-management decision affecting consistency and hardening. |
| Recommendation — Standardise approved image patterns and track configuration changes through release. | ||
| CIS Controls v8 | CIS-4 — Secure Configuration of Enterprise Assets and Software | The question is fundamentally about choosing a manageable secure software baseline. |
| Recommendation — Harden approved images and verify their configuration before deployment. | ||
Practitioner Guidance
What to prioritise: prioritise image lifecycle ownership over image ideology. The better question is which approach your team can rebuild, verify, and patch consistently without drift.
What to verify: confirm that the chosen pattern has a repeatable build process, a dependency inventory, and a clear update path for base layers, certificates, and runtime components. If any of those are manual, the safer choice is usually the simpler curated image.
Decision rule: if the workload has legacy dependencies or frequent churn, prefer curated images; if it is a narrowly defined service with strong build automation and low dependency complexity, scratch may be appropriate.
Practitioner takeaway: the right choice is the one your organisation can sustain over time, because an image that is hard to rebuild and hard to verify becomes a security liability even if it starts out minimal.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 12, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org