A curated open source catalog is only worth using if curation means specific, repeatable checks, not a logo on a registry. At minimum it should cover where the code came from, how it was built, who maintains it, what is known about its flaws, and when it gets removed.
Source and build
Ask whether packages are built from source by the curator or simply mirrored from the public registry. A mirror adds convenience and a cache. A rebuild adds a chance to compare the published artifact with the source it claims to come from.
SLSA frames this well. Its Build track aims to show that the artifact you receive was produced by the expected build platform from the expected source. It also says plainly what it does not cover: code quality, producer intent, and unauthorized source or dependency changes. Curation should fill some of those gaps with human review.
Maintainer and project health
Look for signals that a project can sustain itself and defend itself. OpenSSF Scorecard lists checks you can borrow as criteria:
- code review before merge
- branch protection
- a published security policy
- signed releases
- pinned dependencies
- contributor diversity across organizations
- whether the project is still maintained
None of these proves a project is safe. A single maintainer with no review is a risk you can price in, though.
Advisory handling
A curated catalog should say how it learns about vulnerabilities, how fast it publishes its own advisory, and whether it states if a fix is a backport or a version bump. It should publish data in a format tools can read so patched builds are not flagged as vulnerable.
Admission and removal rules
Write these down before you need them.
- Admission: minimum project health, licence check, reviewed install scripts and a named internal owner.
- Update: how new versions are tested and how long they wait before being offered.
- Removal: what happens when a project is abandoned, relicensed or found malicious, and how consumers are told.
What curation cannot do
Curation reduces risk. It does not review every line of every dependency, and a patient attacker may pass a review. Keep scanning and monitoring in place after admission.
Using the checklist
Score a candidate catalog yes, no or unclear on each item above. Unclear is a no until answered in writing. Run the same list against your own internal registry if you operate one.
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
Is a mirror of a public registry curated?
Not by itself. A mirror caches what upstream publishes. Curation implies review, rebuild or both, plus rules for removal.
Who should own admission decisions internally?
A named team with security and engineering input, so exceptions have an owner and a record.
Sources
Last reviewed: 19 October 2026.
