Dockerfile copies build context with no .dockerignore
ID |
dockerignore_present |
Severity |
low |
Remediation Complexity |
trivial |
Remediation Risk |
low |
Remediation Effort |
low |
Family |
SCM |
Tags |
container, non-reachable, secrets, security, supply-chain |
Description
A .dockerignore declares the files Docker must exclude from the build context — the tree sent to the daemon and available to COPY/ADD. When a Dockerfile does a broad COPY . <dest> / ADD . <dest> and no .dockerignore excludes anything, the entire working tree is baked into image layers: .git (full history, which may contain secrets that were committed and later removed), .env, cloud key files (*.pem, service-account JSON), and CI tokens. Anyone who can pull the image can extract them.
This check reports a project that has a Dockerfile doing a whole-context copy and no .dockerignore.
To avoid false positives, the finding is conditional on the risky pattern. A repository with no Dockerfile, a Dockerfile that copies only specific paths (COPY ./src /app), or one that already ships a .dockerignore is not reported.
|
| This is container-build secret hygiene (CIS Docker Benchmark territory), not an SPVS pipeline/VCS control, so it carries no SPVS tag. |
Security
Secrets baked into an image are one of the most common and most damaging container leaks: image layers are immutable and widely distributed, so a token copied in via COPY . . remains extractable from every registry copy and every pull, even after it is deleted from the source. A .dockerignore is the cheapest, most reliable control — excluded files never enter the build context, so they cannot be copied into a layer. It complements (does not replace) secret scanning.