FDEBench Join us live

Q
154 / 159

Multimodal & voice

A scan of over 300,000 public container images found private keys in more than 28,000 of them. Explain how keys end up in images and how you would prevent it.

question bank FDEBench bank

01
Sketch

Reference sketch

A short answer key carried over from the source. Not yet a graded rubric.

1. Explain the mechanism: the build context is uploaded wholesale, so any file in the directory — .env, .git, key material, cloud credentials — can be copied into a layer by a broad COPY. 2. Emphasise layer immutability: deleting a secret in a later layer does not remove it, the earlier layer still contains it and anyone who can pull the image can read it. 3. Use .dockerignore as the first control, and note it is independent of .gitignore — those rules do not carry over. 4. Cover the three buckets deliberately: secrets (.env, keys, credentials), heavy artefacts (node_modules, build caches, datasets) that slow every build, and noise (.git, editor files) that busts the layer cache. 5. Prefer explicit allow-listing — narrow COPY of exactly the paths needed — over trying to exclude everything dangerous. 6. Use build-time secret mounts rather than build args, since ARG values persist in image metadata. 7. Use multi-stage builds so only the final artefact reaches the shipped image. 8. Enforce it mechanically: secret scanning in CI on the built image, not just the repo, plus a blocking gate before push. 9. Treat any leaked key as compromised — rotate it, since a pushed layer must be assumed to have been pulled.

—