CI pipelines should have read and write access to a vcpkg binary cache, and individual developers should have read only access to what CI produced. That is Microsoft's recommendation, and it makes sense for security: anyone who can write to the cache can change the binaries other people restore.
What the cache is
The vcpkg documentation explains that most ports in the public registry are built from source. When binary caching is on, vcpkg creates a binary package after each build, holding the build output, integration files, usage notes and license. Later runs decide whether to restore the cached package or build from source again.
The default is a files provider in a user directory such as the XDG cache folder or a home cache directory on non Windows systems. Caches can also live on a network share, a NuGet feed, or cloud storage. The documentation notes that binary caching covers only binaries you build, and asset caching handles source files and prebuilt tools.
The trust question
A restored binary is code that skips your compile step. If someone can write a package into the cache under the right key, the next machine that asks for that key runs their build output instead of building from source.
Treat the cache like a package registry you operate. Think about who can publish to it, how the key is derived, and who can read it.
| Role | Suggested access | Reason |
|---|---|---|
| CI pipeline on protected branches | Read and write | Produces the trusted binaries |
| Developer machines | Read only | Consume without altering |
| Pull request builds from forks | Read only or none | Untrusted code should not write |
The documentation's own recommendation, a cache with read and write for every CI pipeline and read only for individual developers, fits the first two rows. The third is our addition and worth applying.
Practical steps
- Put the cache behind authentication. Avoid world writable shares.
- Give pipelines for untrusted pull requests no write credential.
- Keep the cache credentials out of build logs. See pipeline secrets approaches.
- Expire old entries, so a package built with a vulnerable library does not linger.
- After a security fix lands in your baseline, force a rebuild. How the baseline pins versions is explained in vcpkg baseline vs overrides.
- Record the library versions in an SBOM, as in generating an SBOM for a vcpkg project.
What the cache key covers
A new build is triggered when inputs change. We explain the key in the vcpkg ABI hash. Keys decide when a binary is reused, but they are not a signature of who built it.
Safeguard's dependency scanning and SBOM generation can inventory what a build ships. A free scan is at gold.safeguard.sh/scan.
Quick check
Is the default cache shared across a team?
No. The default is a files provider in a per user location. Sharing needs a network share, feed or cloud storage.
Does binary caching cache source downloads?
No. The documentation says it covers only binaries you build, and asset caching handles source files and prebuilt tools.
Sources
Last reviewed: 19 October 2026.
