Check runtime dependencies before choosing Docker scratch

Bottom line: Review the required application runtime environment before accepting a minimal image design. Keep a successful build, a process start and representative application behavior as separate checkpoints instead of using image size as the completion criterion.

Source fact: documented behavior

The Base images documentation is the primary reference.

Docker reserves scratch as a Dockerfile starting point; it cannot be pulled, run or used as an image tag name. The minimal hello example only executes successfully without runtime dependencies, and the guide lists language runtimes, dynamically linked C libraries and CA certificates as examples to consider.

What the source does not establish

This article does not identify every dependency of an application or certify a minimal image as secure. The source example is not evidence that another executable is self-contained. Keep vulnerability-assessment eligibility, build-secret handling and the application runtime review distinct; each answers a different acceptance question.

Applicability questions

• Which runtime requirements does the application actually declare?
• How does the proposed image supply each required component?
• Which representative functions exercise those dependencies?
• Who will resolve an unknown requirement before the base-image choice is accepted?

DSE recommendation: write the runtime contract

DSE recommends a short runtime contract tied to the executable and source revision under review. Begin with the categories named in the source, then use the application’s own primary documentation and build evidence to identify what is genuinely required. Mark an unknown dependency as unresolved instead of describing the package as standalone by assumption.

Trace each required component to the proposed image contents. Review what the Dockerfile deliberately copies and what the application expects to find. If the requirement is better served by a documented base image, assess that option on its own terms rather than adding unexplained files until a startup error disappears.

Separate the small source example from the real acceptance workload. Use it to understand the FROM scratch construction, then identify the application functions that need representative testing. Include the relevant trust, library or language-runtime requirement only when it applies to that application; do not add components merely because the source lists them as possibilities.

Keep the dependency decision reproducible. Retain the executable identity, reviewed requirements and Dockerfile with the acceptance plan. When a dependency is added, removed or changed, revisit the affected application check. Do not substitute a smaller file inventory or a clean scanner display for the required runtime evidence.

Verification and evidence

Proposed verification, not performed: build the documented minimal example in an approved lab to confirm the construction workflow. For a separately reviewed application, prepare an explicit requirement checklist and representative non-sensitive operations that exercise those requirements. Keep the two exercises labeled distinctly.

Collect the actual startup result and application observations, including failures and missing evidence. Reconcile them with the declared runtime contract and investigate the relevant component before changing the image. Retain the Dockerfile, executable identity, required-component record and observed outcomes. Have another reviewer distinguish what the source example demonstrates from what has actually been established for the application.

Official references

• Base images — Docker Docs.

Source review completed October 28, 2026. Recheck the official documentation and deployment-specific applicability before a production change.