Publish your policies once as a versioned bundle and have each repository pull a pinned version in CI, rather than copying files by hand. Conftest can pull policies from a URL, a git repository or an OCI registry, which makes one central policy set practical for many teams.
The copy and paste problem
The first policy usually lives in one repository. Then a second team wants it, so someone copies the file. Six months later there are eight copies, three of them out of date, and nobody can say which version a given service was checked against. A shared bundle fixes that, because there is one source and a version number.
What Conftest supports
The Conftest documentation says policies are often reusable between projects, and the tool supports specifying and downloading dependent policies. The format reuses the bundle defined by Open Policy Agent.
The pull command downloads policies from several kinds of source:
| Source | Use when |
|---|---|
| HTTPS URL | You host a single policy file somewhere reachable |
| Git repository | Policies live in a repo and you want a path inside it |
| OCI registry | You already run a registry and want versioned, immutable artifacts |
The docs also note that policies can be pushed to OCI registries that support the artifact specification, and that for a private or on premises registry you should include the oci scheme in the address, so Conftest uses its OCI downloader rather than guessing from the hostname.
Authentication details differ per source, so follow the documentation for your registry and keep credentials in your CI secret store, not in the repository.
A rollout pattern
- Create a policy repository. Keep policies, tests and a short readme together.
- Test on every change. See how to unit test a policy as code rule.
- Publish tagged versions. Push each release to your registry with a version tag.
- Pull a pinned version in CI. Each service names the version it uses. Do not pull a moving tag like latest into a blocking check.
- Move versions on purpose. When you release a stricter policy, announce it and give teams a window to move.
- Report which version each service uses. That answers the audit question about what a build was checked against.
Decisions to make
- One bundle or several? Split by audience if the rules differ a lot, for example one for Kubernetes manifests and one for infrastructure code. Too many bundles are hard to track.
- Who can publish? Restrict write access to the registry or repo, since a policy change affects every consumer.
- How fast can a change reach everyone? For urgent fixes, plan an out of band route, and tell teams how to pick it up.
What can go wrong
A shared policy that changes under teams without warning will cause broken builds and erode trust. Pinning versions and announcing changes keeps policy updates predictable. A policy shipped in warn mode first, then raised to blocking in a later version, gives teams a safe runway.
Where Safeguard fits
Safeguard centralises policies, gates and guardrails, and applies them across the repositories and pipelines you connect, so you do not have to distribute files yourself for dependency and supply chain rules. You can try a free scan at gold.safeguard.sh/scan.
Quick check
Should every repository pull the latest policy automatically?
Not for blocking rules. Pin a version, then upgrade deliberately, so a policy change cannot break many builds at once.
Do I need an OCI registry to share policies?
No. A git repository or an HTTPS URL also works. An OCI registry adds versioned artifacts if you already run one.
Sources
Last reviewed: 19 October 2026.
