The XZ Utils backdoor taught the industry a painful lesson: the biggest risk in your open-source supply chain is not always a known vulnerability. Sometimes it is a project with a single, burned-out maintainer who hands commit access to a social engineering attacker.
Safeguard Open Source Manager exists to surface exactly this kind of risk -- the risks that vulnerability scanners miss entirely.
Beyond CVE Counts
Every SCA tool on the market will tell you about known vulnerabilities in your dependencies. That is table stakes. But known vulnerabilities are only one dimension of open-source risk.
Consider the dependencies in a typical enterprise application. You might have 500 direct and transitive dependencies. Of those:
- 30 to 50 might have known vulnerabilities at any given time
- 150 might not have had a release in over a year
- 20 might be maintained by a single individual with no backup
- 10 might have had their repository transferred to a new owner in the last 12 months
- 5 might have build processes that are not reproducible
Each of those conditions is a risk factor. A dependency maintained by one person who has not published a release in 18 months is a ticking time bomb even if it has zero known CVEs today. When a vulnerability is eventually found, there may be nobody to fix it. And if someone does step in to "help" maintain it, you have the XZ Utils scenario.
Open Source Manager tracks these risk factors systematically.
What We Measure
Open Source Manager evaluates each open-source dependency across five dimensions.
Maintenance Activity
We track commit frequency, release cadence, issue response time, and pull request merge time. A project that has regular commits, ships releases on a predictable schedule, and responds to issues within days is healthier than one with sporadic activity and a growing backlog of unaddressed issues.
We also track trends. A project that was active 12 months ago but has seen declining activity is a different risk profile than one that has always had low activity. Declining activity often signals maintainer fatigue or a project approaching abandonment.
Maintainer Diversity
Single-maintainer projects are a concentration risk. If that one person loses interest, gets hired away, burns out, or is compromised, the project stalls or worse. We measure the number of active contributors, the distribution of commits across contributors (bus factor), and whether the project has an organizational sponsor.
Projects with a healthy contributor base -- multiple active committers, an organizational backer, and documented succession plans -- score higher on this dimension. Projects where one person accounts for 95% of commits get flagged.
Security Practices
We evaluate whether the project follows security best practices:
- Signed releases -- Are releases cryptographically signed?
- Branch protection -- Are main branches protected against force pushes?
- CI/CD security -- Does the build pipeline have appropriate controls?
- Security policy -- Does the project have a SECURITY.md with vulnerability reporting instructions?
- Dependency management -- Does the project actively manage its own dependencies?
These factors are drawn from the OpenSSF Scorecard methodology, extended with our own criteria based on real-world supply chain incidents.
Vulnerability History
Beyond current CVEs, we look at historical vulnerability patterns. A project that has had repeated critical vulnerabilities in similar code areas suggests systemic code quality issues. A project with a fast patch-to-release cycle for security issues demonstrates good security responsiveness even if it has had vulnerabilities.
We also track whether the project participates in coordinated disclosure and whether security fixes are backported to maintained release branches.
License and Legal
We catalog the project's license and check for compatibility with common enterprise license policies. We also flag projects that have changed licenses (which can create compliance complications for existing users) and projects with inconsistent licensing across files.
The Health Score
These five dimensions are combined into an overall health score for each dependency. The score is not a black box -- it decomposes into the contributing factors so you can understand exactly what is driving the assessment.
Health scores are updated continuously as new data becomes available. When a maintainer stops committing, the score adjusts. When a project adds branch protection, the score improves. When a vulnerability goes unpatched for an extended period, the score degrades.
The scores are relative to the ecosystem. A Python package is compared against Python package norms, not against a Rust crate. This accounts for the different community standards and tooling conventions across ecosystems.
How Customers Use It
Dependency Selection
When developers are evaluating which library to use for a particular function, Open Source Manager provides an objective basis for comparison. Two libraries might have similar functionality, but if one has three active maintainers, signed releases, and a security response team, while the other has one maintainer and no security policy, the choice is clear.
We integrate this into the developer workflow through IDE extensions and CLI tools. When a developer adds a new dependency, they see the health score before they commit. This shifts the risk assessment left, to the point where the decision is actually being made.
Portfolio Risk Assessment
Security teams use Open Source Manager to assess open-source risk across their entire portfolio. The dashboard shows the distribution of health scores across all dependencies, highlighting the highest-risk components that need attention.
This portfolio view often reveals concentration risks that are invisible at the individual product level. If 40 of your products depend on the same single-maintainer library, that is a portfolio-level risk that only surfaces when you look across products.
Proactive Risk Mitigation
Instead of waiting for a vulnerability to be discovered in a risky dependency, Open Source Manager enables proactive mitigation. When a dependency's health score drops below your threshold, you can:
- Begin evaluating alternative libraries before a crisis forces a rushed migration
- Engage with the project community to support sustainability (sponsorship, contributions)
- Add compensating controls (additional testing, sandboxing) for high-risk dependencies
- Prioritize updating to versions with better security characteristics
Vendor Conversations
For organizations that use Safeguard TPRM, Open Source Manager data enriches vendor risk assessments. When a vendor's product depends on unhealthy open-source components, that is a specific, evidence-based concern to raise in vendor reviews.
Technical Integration
Open Source Manager data is available through the same API and interfaces as the rest of the Safeguard platform. Health scores appear in SBOM views, vulnerability reports, and policy evaluations.
Policies can reference health scores. For example, you can create a policy that flags any new dependency with a health score below 50, or that blocks releases containing dependencies from projects with zero active maintainers.
The data feeds from multiple sources: GitHub API, package registry metadata, release signing verification, and our own continuous analysis of project activity. We cache and normalize this data so that health score queries are fast even when the underlying sources are rate-limited.
Getting Started
Open Source Manager works on top of your existing SBOM data in Safeguard. If you are already managing SBOMs through ESSCM, enabling Open Source Manager adds health analysis to every component in your inventory.
The initial analysis runs within minutes of enablement. From there, scores are updated continuously. No additional configuration is required -- the system automatically identifies open-source components from your SBOMs and begins tracking their health.
Start by reviewing your lowest-scoring dependencies. Those are the ones most likely to cause problems, and addressing them proactively is significantly cheaper than responding to an incident.