The direct answer
Do not put private build input into Dockerfile ENV and treat a later unset as proof that the image no longer contains it. Use a supported temporary build-secret input path when appropriate, then independently review what the consuming instruction can publish or retain. A temporary mount does not establish a clean image, trusted consumer or complete deletion.
Decide whether the runtime image needs the input at all
An AI preprocessing worker depends on an approved private package. Building the worker needs temporary dependency-access input; running the resulting worker does not. A proposed build puts that input into the image environment, uses it and later unsets it. A reviewer sees a tidy final environment and approves distribution.
The missing decision is the build-input channel, not whether the worker can complete its ordinary task. The dependency guide still owns source, graph and backend admission. This worksheet adds a distinct retention question before the image is released. It does not choose a package, registry, builder deployment or credential provider.
Distinguish Dockerfile ENV from temporary shell state
Docker’s build best-practices reference says a Dockerfile ENV value persists in its intermediate layer and can be recovered even when unset in a later layer. Its separate single-instruction shell example is not the same mechanism. A later shell unset is no assurance that an earlier Dockerfile ENV record disappeared.
For the invented review, reject private input in Dockerfile ENV rather than accepting a cleanup explanation. Do not generalize this into a claim about every possible image format, filesystem deletion, metadata rewrite or builder cache. We have inspected none of them.
Also distinguish two questions: whether the worker’s final process receives a value and whether a distributed or retained artifact contains it. Evidence for one cannot stand in for the other. A reviewer should record the exact input channel and retention scope, rather than write “environment cleaned” without identifying what was examined.
Select one temporary input contract without extending its promise
Docker’s build-secrets guide rejects build arguments and persistent environment variables for secrets. A secret mount makes client-supplied input available for the build instruction’s duration. Consumption is a separate step from supplying it. Mounts can expose files or environment variables; these temporary targets differ from Dockerfile ENV.
This worksheet selects only a file-target secret mount for one fixed, independently reviewed consumer instruction. It supplies no command, Dockerfile, private path, input value or configuration. Host-side source selection and any temporary environment-target alternative are outside this particular review, not declared universally forbidden.
The sources are maintained, unversioned Docker documentation; no displayed numeric Docker or BuildKit release establishes our environment. Require independent evidence that the actual builder, frontend and selected input/consumer path support the plan. Unknown support means hold, never fallback to a persistent channel merely to make a build succeed.
Give the consumer and its outputs their own review
Invent build B-A, private input reference K-A and fixed consumer C-A. These labels are inert associations, not credentials or actual artifacts. K-A is authorized only for the declared dependency-access purpose; C-A must not treat it as application content or include it in the runtime worker’s settings.
A temporary input can still be read by its consumer. Therefore review the complete consumer and invoked dependencies, its declared output set, diagnostics, error handling and retained build artifacts. If C-A copies input-derived private bytes into an output, the channel choice does not authorize releasing that output. This is a proposed information-flow rule, not a demonstrated Docker scanner or confinement mechanism.
| Boundary | Required independent decision |
|---|---|
| Need and authority | K-A is necessary for the fixed approved purpose, with current owner authorization. |
| Supply and consumption | Supported temporary file-target input reaches only the admitted C-A plan. |
| Consumer baseline | C-A and invoked dependencies match the independently reviewed build graph. |
| Retained products | Image/output/log/cache scopes have explicit supported handling and release evidence. |
| Distribution | The exact reviewed result and intended audience satisfy current policy. |
The useful positive is conditional build-plan eligibility after every field is established. Actual builder support, input ownership, consumer behavior, output handling and distribution evidence are unimplemented or unknown here. No real build or artifact is admitted.
Walk eight inert build-input cards
Every card is PROPOSED_UNRUN. No private value or generated image is needed to discuss the decision.
| Card | Condition | Proposed disposition |
|---|---|---|
| 1. Ordinary dependency | Complete supported B-A/K-A/C-A plan and independently approved outputs. | Conditionally admit the input plan, not a completed build. |
| 2. ENV then unset | Private input enters Dockerfile ENV before later cleanup. | Reject that retention assurance. |
| 3. Argument substitute | A build argument replaces the chosen temporary input channel. | Reject the changed plan; convenience supplies no approval. |
| 4. Copied output | C-A writes private input-derived bytes into distributed output. | Withhold release despite temporary availability. |
| 5. Diagnostic uncertainty | Logs, errors or cache outputs lack supported handling. | Hold confidentiality evidence; name unresolved scope. |
| 6. Changed consumer | An unreviewed backend or dependency now consumes K-A. | Reject changed code authority. |
| 7. Unavailable input | Input or selected builder support is missing. | Hold; no persistent-channel fallback. |
| 8. Clean-looking runtime | Final process environment looks clean but artifact review is incomplete. | No distribution assurance from that observation alone. |
Report retained scope instead of promising erasure
If an earlier artifact may contain private input, preserve its unresolved disposition and follow the owner’s authorized incident process. Do not present a later build change as recalling already distributed copies. The retained-copy guide supplies the broader lifecycle distinction; this worksheet supplies no image-history rewrite, cache purge, credential rotation or recovery procedure.
No Docker command, build, image, layer, environment, secret, mount, log, cache, container or runtime was created, inspected or exercised for these cases. Only documentation and editorial work occurred. Boundary remains prelaunch with planned request-path checks, not a shipped build-secret manager or clean-image verifier. Its mock policy evidence concerns different behavior.
Primary sources
Official references supporting the guidance. Examples in this guide are synthetic and are not reports of a production incident.