Often not. A library fetched with curl, wget or ADD in a Dockerfile has no package manager record, so a manifest scan cannot see it and an image scan may not recognise it. It is visible only if the scanner fingerprints files or you record the download yourself.
Why this blind spot exists
Scanners read declarations: manifests, lockfiles, package databases. A download line is an instruction, not a declaration. The file lands in the image as an anonymous archive or binary.
The Docker best practices guide notes that ADD supports fetching files from remote HTTPS and Git URLs, and that it is best when you need to download a remote artifact as part of the build. It also supports checksum validation of the remote resource. That checksum is useful twice: it protects the build and it gives you a verifiable identity for inventory.
What each scan type sees
| Scan | Sees the downloaded library? |
|---|---|
| Source manifest scan | No, nothing is declared |
| Dockerfile scan | Sees the line, rarely the version risk |
| Image package scan | Only if installed through a package manager |
| File fingerprint or binary scan | Possibly, depending on the library |
How to make it visible
- Pin the version in an ARG at the top of the Dockerfile and use that ARG in the URL. The version is now one greppable line.
- Add a checksum to the download, using the ADD checksum option documented by Docker, so a swapped artifact fails the build.
- Write a short inventory file in the repository, such as
third-party.md, listing name, version, source URL and checksum for every download. - Emit that list into your SBOM as components with purls, so downstream tools can match advisories.
- Prefer a package manager install when one exists. It leaves a record.
Here is the pattern in a Dockerfile.
ARG TOOL_VERSION=1.2.3
ARG TOOL_SHA256=replace_with_the_published_checksum
ADD --checksum=sha256:${TOOL_SHA256} https://example.com/tool-${TOOL_VERSION}.tar.gz /tmp/
The URL and values above are placeholders. Use the real published checksum from the vendor.
Keep it in the final image only if needed
A multi-stage build can download and compile in an early stage, then copy only the result forward. The builder stage scan still matters, as covered in detecting vulnerabilities in multi-stage Docker builds, because the compile stage held the sources.
Try it yourself
Click through it at your own pace, or open it full screen. Compare what the scan lists against what a Dockerfile could add outside a package manager.
Safeguard offers SBOM and dependency scanning, plus a free scan at gold.safeguard.sh/scan. A recorded inventory makes any scanner more accurate.
Quick check
Is curl in a Dockerfile worse than ADD?
Both fetch without a manifest. ADD with a checksum gives built in verification, and Docker's guide describes it as giving a more precise build cache than a manual download.
Do I need to record every download?
Record every one that ends up in the final image or runs in the build. They are the ones advisories can affect.
Sources
Last reviewed: 19 October 2026.
