Neelu Tripathy and Lovlesh Malik (Adobe) argue that the "golden image" (the hardened base VM or container image every workload starts from) is one of the most trusted and least scrutinised links in the software supply chain. Traditional golden images are built by hand or by imperative scripts, drift from their intended state, and are rarely signed or traceable. Their alternative is a self-healing image supply chain: declarative builds, automated updates, baked-in hardening, custom-build support, and signed, attested, immutable artifacts, all in one pipeline. Their closing line sums it up: "Immutability is the only patch that never fails."
Post 21 of my Black Hat Asia 2026 series. The published deck is mostly architecture diagrams, a pipeline demo video and results charts, so I focus on the design principles it lays out rather than on numbers I cannot verify from the text. For the registry side of the same story, see the package-registry talk.
1. Why the golden image matters
Every server, VM or container you launch inherits whatever is in its base image: OS packages, agents, configuration, credentials that leaked into layers, and vulnerabilities. If the base is compromised or simply stale, everything built on it is too, at scale. Yet many organisations still treat the golden image as a one-off artefact produced by an admin or a script and then copied around.
The talk names four recurring problems:
- Supply-chain integrity: do you know exactly where each package in the image came from, and can you prove the image was not altered after the build?
- Security drift: images age. New CVEs land, configurations diverge between teams, and running instances slowly stop matching the approved baseline.
- Usability versus security: if the hardened image is hard to customise, teams build their own unofficial images and bypass the controls.
- Ownership and governance: who is responsible for the image, and how are exceptions approved? Add multi-architecture and multi-cloud requirements and the manual approach stops scaling.
2. The properties a good image builder needs
| Group | Properties | Why it matters |
|---|---|---|
| Integrity | Reproducibility, hermeticity, immutability | Same inputs give the same image; nothing sneaks in during the build; nothing changes after |
| Authenticity | Verifiability, traceability, auditability | You can prove who built it, from what, and when |
| Security | Visibility, hardening | Know what is inside; reduce attack surface |
| Adoptability | Usability, extensibility, customisability | Teams use the official path instead of working around it |
The design tension is deliberate: the first three groups push toward locked-down control, the last pulls toward flexibility. The pipeline described below tries to give both.
3. The five design techniques
Fig. 1 — A rebuild-driven pipeline: fix the definition, rebuild, re-verify, replace.
3.1 Declarative builds
Instead of a script that does things to a machine, you write a definition of the desired end state: which base, which packages, which agents, which hardening profile. Declarative state-based definitions improve hermeticity (the build depends only on declared inputs), immutability, minimalism, repeatability and consistency, and they leave less build-time residue. Because the definition is code, policy-as-code checks can be enforced in review. Typical contents include the EDR agent, configuration hardening, and other agents, along with SBOM generation and versioning.
3.2 Automated updates
Drift is fought with automation, not reminders. The image lifecycle is managed with explicit triggers: a new upstream release, a new vulnerability, a policy change. A pre-service image that fails tests never ships. An in-service image that fails a later scan is flagged and rebuilt. State changes are tracked so every image has a known status: pre-service, in-service, failed or retired. This is the "self-healing" part: rather than patching running machines in place, you replace them with a fresh, verified image.
3.3 Security and hardening
Baked in at build time: allow-listing official package sources, attack-surface reduction (remove what you do not need), configuration hardening, deploying required security agents, then functional testing and security scanning before the image reaches the registry. Doing this at build time means the protection is present from the first boot, not applied later by a possibly-missed script.
3.4 Custom builds
To avoid shadow images, the platform lets teams add their own packages under the same guardrails. Every build produces an SBOM (a bill of materials listing libraries and dependencies), provenance records, and build attestations, with policy-as-code applied to the custom additions too. Usability is a security control here: the easy path must be the secure path.
3.5 Signing and verification
The trust anchor. Builds are deterministic where possible, SBOMs are generated automatically, and artefacts are cryptographically signed with attestations produced by executing attestors. A PKI issues the certificates, a signing-and-verification service handles operations, and images land in an immutable registry. Consumers verify signatures before they run an image, so a tampered or unofficial image is rejected at deploy time rather than discovered later.
4. Platform, personas and workflow
The talk moves from principles to an implemented platform with defined user personas (for example platform engineers who own the base and application teams who customise it), a workflow covering request, build, test, sign and publish, and a recorded end-to-end demo of the build-and-deploy pipeline. It also addresses engineering challenges such as multi-architecture builds and multi-cloud distribution, and scaling the pipeline as the number of images grows. The results section is presented as charts in the deck; I do not restate figures I cannot read from the text, so check the original slides for the measured improvements.
5. Honest trade-offs
| Choice | Benefit | Cost |
|---|---|---|
| Replace instead of patch | No configuration drift; easy rollback | Needs stateless workloads and good automation |
| Hermetic builds | Harder to poison via the network | You must mirror or vendor dependencies |
| Mandatory signing | Tamper evidence | Key management and PKI operations burden |
| Custom build support | Fewer shadow images | More policy surface to maintain |
A caution the deck's slogan can mask: immutability prevents change after build, not vulnerabilities present at build. If the definition pulls a flawed package, you get a flawed but perfectly reproducible image. Scanning and up-to-date sources remain essential, and so does watching the inputs, which is exactly where registry attacks happen.
6. How to start small
- Pick one base image and write its definition as code in version control.
- Generate an SBOM on every build and store it beside the image.
- Restrict package sources to an allow-list or an internal mirror.
- Add a scan gate that fails the build on policy violations.
- Sign the result and verify at deploy, initially in audit mode.
- Add a scheduled rebuild plus a trigger on new critical CVEs.
What is a golden image?
The approved, hardened base image (VM template or container base) from which workloads are launched. "Golden" means it is the trusted starting point.
What does "self-healing" mean here?
Not patching in place. When the definition or an upstream input changes, the pipeline rebuilds, re-tests, re-signs and publishes a new image, and workloads are replaced with it.
Why declarative rather than scripts?
A declared end state is reviewable, repeatable and checkable by policy. Imperative scripts depend on the starting condition and leave residue.
Do I need to be Adobe-sized for this?
No. The principles (definition as code, SBOM, allow-listed sources, signing, verification) apply at any scale; the platform investment scales with how many images you manage.
Takeaways
- The golden image is a high-leverage supply-chain link: compromise or staleness propagates to every workload.
- Build it declaratively so it is reproducible, hermetic and policy-checkable.
- Fight drift with triggered rebuilds and replacement, not manual patching.
- Generate SBOMs, provenance and attestations, sign them, and verify at deploy.
- Make the secure path the easy path with custom-build support, or teams will route around you.
References & further reading
- Black Hat Asia 2026 — this talk's official page — abstract, speaker bio, and slides/video when posted.
- Official talk recording on YouTube — Black Hat channel.
- Black Hat Asia 2026 — full Briefings schedule — every talk in the conference.
- Sigstore — open tooling for signing and verifying software artefacts.
- SLSA framework — supply-chain levels for provenance and build integrity.
- Anchore: software supply chain security in 2025 — one of the talk's cited resources.
- Sysdig 2025 Cloud-Native Security and Usage Report — also cited in the deck.