Open-source software powers everything. The statistic that 90% or more of modern applications contain open-source components has been repeated so often it has lost its punch. But the operational question behind that number remains largely unanswered for most organizations: do you actually know what open source you are running, and is any of it about to cause you a problem?
That is the question Safeguard's Open Source Manager was built to answer. We launched the initial version in late 2025 alongside Safeguard v5.3, and since then it has become one of the most-used features on the platform. This post walks through what it does, how it works under the hood, and where we are taking it next.
The Problem With Existing Approaches
Most organizations manage open-source dependencies in one of three ways, and all three have significant gaps.
Manual tracking via spreadsheets. This still happens more often than anyone in the industry likes to admit. A team maintains a list of approved libraries, reviews new additions during code review, and updates the list periodically. It works until it does not — which is usually when someone adds a transitive dependency that nobody notices until it shows up in a vulnerability scan six months later.
SCA tools with no governance layer. Software Composition Analysis tools are excellent at identifying what open-source components exist in your codebase. They are less good at answering governance questions: Is this library maintained? Does its license conflict with our distribution model? Has the maintainer changed recently? Does it meet our organization's risk appetite? SCA gives you the inventory. Governance tells you what to do with it.
Ad-hoc policies with no enforcement. Some organizations write open-source policies — approved licenses, minimum maintenance requirements, vulnerability thresholds — but have no automated way to enforce them. The policy exists in a document. Compliance depends on human discipline. This works about as well as you would expect.
What Open Source Manager Does
Open Source Manager sits on top of Safeguard's SBOM engine and adds three layers that transform raw component data into actionable governance.
Component Health Scoring
Every open-source component in your portfolio receives a health score based on multiple signals:
- Maintenance activity — commit frequency, release cadence, issue response time
- Community health — number of active contributors, bus factor, project governance model
- Security posture — history of vulnerabilities, response time to disclosed CVEs, presence of security policies
- Dependency depth — how many transitive dependencies the component pulls in, and their respective health
- Popularity and adoption — download counts, dependent projects, usage across the ecosystem
These signals are weighted and combined into a score between 0 and 100. A score below 40 flags the component as high-risk. Between 40 and 70 is moderate. Above 70 is healthy.
The scoring model is transparent — you can see exactly which signals contributed to a component's score and why. We deliberately avoided a black-box approach because governance decisions need to be explainable, especially in regulated industries.
License Compliance Engine
License management is one of those problems that seems straightforward until you look at the details. A project may use the MIT License, but one of its transitive dependencies uses AGPL-3.0. If your application is distributed commercially, that transitive dependency just created a legal exposure that your license scan of direct dependencies would miss.
Open Source Manager resolves the full license tree for every component, including transitive dependencies. It maps each license to your organization's policy — which licenses are approved for which use cases — and flags conflicts automatically. The engine understands license compatibility rules, so it can identify not just individual license issues but combinations that create problems.
We also handle the messy cases that trip up simpler tools: dual-licensed packages, packages with no declared license, packages whose license file contradicts their package metadata, and packages that changed licenses between versions.
Policy Gates
This is where governance becomes enforcement. Open Source Manager lets you define policies that are evaluated automatically during CI/CD:
- Block components below a health score threshold. If a library's health drops below your acceptable level, the build fails.
- Block prohibited licenses. If a dependency introduces a license that conflicts with your distribution model, the pipeline stops.
- Require vulnerability remediation within SLA. If a component has a known CVE above a certain severity and no fix has been applied within your defined SLA, deployments are blocked.
- Restrict new dependencies. Require approval for any new open-source component that was not previously in your portfolio.
- Enforce version currency. Block deployments that use components more than N versions behind the latest release.
Policies are defined as code, version-controlled, and applied consistently across all projects. No exceptions, no "we will fix it next sprint" deferrals.
Architecture Under the Hood
Open Source Manager is built on top of three data pipelines that run continuously:
SBOM ingestion pipeline. Every time a build runs, Safeguard generates or ingests an SBOM and extracts the component list. This feeds the component inventory for the organization.
Enrichment pipeline. Component identifiers are resolved against multiple data sources — package registries (npm, PyPI, Maven Central, crates.io, etc.), vulnerability databases (NVD, OSV, GitHub Advisory Database), and project metadata from source repositories. This pipeline updates health scores and license information on a rolling basis.
Policy evaluation pipeline. When a build triggers a gate, the policy engine evaluates the current state of every component against the organization's policy set and returns a pass/fail decision with detailed reasoning for any failures.
The enrichment pipeline is the most complex piece. Package ecosystems are inconsistent in what metadata they expose, how they handle versioning, and how they report maintainer changes. We built adapters for each major ecosystem and normalize the data into a common schema before scoring.
Real-World Impact
Since launching Open Source Manager, we have seen some patterns across our customer base that are worth sharing.
The average enterprise portfolio has 12% of components with a health score below 40. Most of these are transitive dependencies that nobody chose intentionally. They were pulled in by a direct dependency and never evaluated. This is the dependency governance gap that spreadsheets and basic SCA tools miss entirely.
License conflicts are more common than people think. Roughly 8% of organizations we onboard have at least one license conflict in their production codebase that they did not know about. The most common pattern is a copyleft dependency buried three or four levels deep in the dependency tree.
Policy gates reduce new vulnerability introductions by 60%. Organizations that enforce health score and version currency policies see significantly fewer new vulnerabilities introduced per release cycle. This makes sense — if you block unhealthy and outdated dependencies at the gate, you avoid the vulnerabilities they carry before they reach production.
What Is Coming Next
We are actively working on several enhancements for Open Source Manager:
Alternative component recommendations. When a component fails a policy gate, the system will suggest alternative packages that provide similar functionality but meet your governance requirements.
Maintainer change detection. Automatic alerting when a component's maintainer changes, which is a key indicator in supply chain attack patterns like the xz Utils incident.
SBOM-to-SBOM diff. Visual comparison between SBOM versions showing exactly which components were added, removed, or changed between releases.
Organizational component catalog. A curated, pre-approved list of components that teams can draw from without triggering approval workflows, reducing friction for common libraries.
How Safeguard.sh Helps
Safeguard's Open Source Manager provides the governance layer that turns raw SBOM data into enforceable open-source policy. It continuously evaluates component health, resolves license compliance across the full dependency tree, and enforces organizational policies as automated pipeline gates. Combined with Griffin AI for natural-language queries across your entire component inventory, Open Source Manager gives engineering and security teams the visibility and control they need to use open source confidently at scale.