An internal curated registry gives developers a single place to pull approved open source packages, with your rules applied once instead of in every repository. Build it in stages: decide scope, set admission rules, add builds, control updates, plan removals and measure use.
Step 1: Pick a narrow scope
Start with one ecosystem and the packages already in heavy use. A registry that covers everything on day one will be bypassed on day two. Pull a list of your top direct dependencies and begin there.
Step 2: Write admission rules
Keep them short enough that people follow them.
- A named owner for each admitted package.
- Licence on the approved list.
- Minimum project health. OpenSSF Scorecard offers automated checks, such as code review, branch protection, signed releases and whether the project is maintained, that you can use as a starting rubric.
- Reviewed install and build scripts.
Step 3: Add build verification
Mirroring is a start. Rebuilding from source in a controlled pipeline lets you compare your result with the published artifact. SLSA's Build track describes the goal: evidence that an artifact came from the expected source on the expected platform. It does not cover code quality or deliberate malice by a producer, so keep human review on high risk packages.
Step 4: Control updates
- Set a short waiting period before new releases are offered, with a fast lane for security fixes.
- Run your own tests against a new version before publishing it.
- Make advisories visible in the registry so developers see why a version is blocked.
Step 5: Plan removal
Decide in advance how you handle a package found malicious or abandoned. Define who can pull it, how consuming teams are told, and how builds fail safely. Test this once with a harmless package.
Step 6: Measure
- Share of builds pulling through the registry.
- Time from advisory to a fixed version being offered.
- Number of exception requests, and why.
A high exception rate usually means the rules are wrong, not the developers.
Pitfalls
- Allowing direct access to public registries from CI, which defeats the point.
- Treating admission as permanent. Re-score packages on a schedule.
- No owner for the registry itself. Give it an on-call rota.
Safeguard covers the inventory and prioritisation parts of this with SBOM and dependency scanning and reachability analysis, and you can try a free scan at gold.safeguard.sh/scan. Autonomous remediation with fix PRs is off by default, and every category starts on Manual, so a person approves changes.
Quick check
Do I need to rebuild every package?
Not at first. Mirror low risk packages and rebuild the ones that are critical or have weak project health.
How do I stop developers bypassing the registry?
Block direct registry access from CI and make the registry faster and easier than the alternative.
Sources
Last reviewed: 19 October 2026.
