Problem
Mixing curl and wget in the same build without policy creates inconsistent download behavior and unnecessary package bloat. Action: standardize on one downloader pattern and enforce secure flags in every image.
Description
Different tools have different defaults for TLS validation, retries, and error handling. That inconsistency makes failures harder to reproduce and debug. Action: define one approved download command pattern with fail-fast behavior and explicit retry policy.
Supply-chain security depends on consistent artifact handling. If one script verifies checksums while another executes downloaded content directly, risk posture becomes uneven. Action: require checksum or signature verification for every downloaded executable artifact.
Removing redundant downloader packages also shrinks vulnerability surface and maintenance overhead. One standard tool per image is usually enough. Action: audit base images and remove unused fetch utilities from runtime layers.
Use this rollout checklist to standardize safely:
- Choose one approved downloader (
curlorwget) per environment. - Enforce strict flags (
-f,-sS, TLS checks, and retry settings). - Verify checksums or signatures before execution.
- Block ad-hoc download patterns with lint rules and PR checks.
Treat verification as part of the rule, not optional cleanup. Action: automate a static check, a build check, and a runtime smoke check in the default CI pipeline so regressions are caught before review.
- Static check: fail when the disallowed pattern appears in Dockerfile or manifest.
- Build check: run a minimal image build to confirm the secure pattern is valid.
- Runtime check: start the workload and assert expected behavior with one deterministic probe.
Examples of code
Problematic code
FROM ubuntu:24.04
RUN wget -O tool.sh https://example.com/tool.sh && curl -sSL https://example.com/tool2.sh -o tool2.shVerified code
FROM ubuntu:24.04
RUN curl -fsSL --retry 3 https://example.com/tool.sh -o /tmp/tool.sh && echo "<sha256> /tmp/tool.sh" | sha256sum -c -