To prove a build used your internal mirror, combine four records: the build tool configuration pointing at the mirror, a lockfile with integrity hashes, the mirror's access log for that build, and a network rule showing the build could not reach public registries. Any one alone is a claim; together they are evidence.
Why a setting is not enough
Saying "our npm config points at the mirror" proves intent. It does not prove what happened on Tuesday at 14:02. A developer can override a registry URL in a project file, a script can download from a raw URL, and a cached layer can hide a fetch. Auditors in regulated environments tend to ask what stops the exception, not whether a policy exists.
The four pieces of evidence
1. Configuration as code. Store the registry settings in a file under version control, owned by the platform team, and show its history. Project level overrides should be blocked or flagged by review.
2. Lockfile with hashes. A lockfile records exact versions and, in most ecosystems, content hashes. If the build installs from the lockfile and fails on a hash mismatch, you can tie the installed bytes to what was approved.
3. Mirror access log. The mirror records which client fetched which package and version, and when. Match the log window to the build start and end time. A build that resolved forty packages should show forty requests, or cache hits you can explain.
4. Egress control. If build runners cannot reach public registry hosts, then fetching from them is impossible, not just discouraged. Keep the firewall or proxy rule, its change history and a periodic test that proves it blocks. Our post on an egress allowlist you can actually enforce covers the design.
A simple reconciliation you can run
For a sampled build, produce a short record:
- Build ID, commit and time window.
- The lockfile at that commit, listing package, version and hash.
- The mirror log lines for the build's client identity in that window.
- A comparison showing each locked package appears in the log or in a documented cache.
- The egress rule version in force that day.
Do this for a handful of builds each quarter and keep the results with your other evidence. If a build has a gap, record what you found and how you fixed it. Finding a gap yourself reads far better than having it found for you.
Common gaps
- Base images pulled from a public registry while language packages use the mirror.
- Build scripts that call curl against a vendor download URL.
- Cached dependencies on long-lived runners that predate a mirror policy.
- Developer laptops that publish artifacts without a clean build.
Each gap has a fix: mirror the image registry too, ban downloads in scripts or route them through the mirror, use ephemeral runners, and build releases only in CI.
Quick check
Is a lockfile alone proof of the source?
No. It proves versions and hashes, which helps, but not the host the files came from. Pair it with mirror logs and egress rules.
How long should mirror logs be kept?
Match the retention of your other change and audit records, and confirm the period with your auditor or compliance owner.
Safeguard's SBOM and dependency scanning can record what a build contained so you can compare it to the log. Try the free scan at gold.safeguard.sh/scan.
Last reviewed: 19 October 2026.
