The open source risk conversation has been stuck on vulnerabilities for too long. Ask most security teams how they manage open source risk, and the answer is SCA scanning -- running Software Composition Analysis tools to find known CVEs in their dependencies. This is essential, but it is only one dimension of a multi-dimensional risk problem.
Known vulnerabilities represent the risks that have already been discovered and documented. They are the risks you can Google. The harder risks are the ones that do not have CVE numbers yet: the abandoned project that will never get another security patch, the single maintainer who is burning out, the dependency that just changed ownership to an unknown entity, the package name that is one typo away from a popular library.
A genuine open source risk intelligence platform needs to assess all of these dimensions. Here is what that looks like in practice.
The Five Dimensions of Open Source Risk
1. Known Vulnerabilities
This is the table stakes dimension. Every SCA tool does this. The relevant questions are:
- Does your scanning cover all package ecosystems you use (npm, PyPI, Maven, Go, Cargo, NuGet, RubyGems)?
- Are you scanning transitive dependencies, not just direct ones?
- How current is your vulnerability database? Hours behind or days behind the NVD?
- Are you using EPSS scores and VEX data to prioritize, or just CVSS?
The state of the art in vulnerability scanning is well-established. The differentiation comes from data freshness, ecosystem coverage, and prioritization intelligence.
2. Maintainer and Project Health
This dimension is less mature but arguably more important for long-term risk. A project's health predicts whether future vulnerabilities will be fixed promptly or ignored entirely.
Key health indicators include:
Maintainer activity: When was the last commit? The last release? Are issues being triaged and responded to? A project with no commits in 12 months is not necessarily dead, but it is a risk signal.
Bus factor: How many active maintainers does the project have? If the answer is one, your dependency on that project is a dependency on a single individual's health, motivation, and availability. The xz Utils incident demonstrated this risk vividly.
Security responsiveness: When security issues are reported, how quickly are they addressed? Does the project have a SECURITY.md file? A coordinated disclosure policy? A history of CVE assignment and timely patches?
Funding and sustainability: Is the project funded through corporate sponsorship, grants, or donations? Or is it maintained purely through volunteer effort? Projects with sustainable funding models are more likely to provide consistent security support.
Community engagement: Is the project attracting new contributors, or is the contributor base shrinking? Growing projects are more resilient. Shrinking projects are at higher risk of abandonment.
3. Supply Chain Integrity
This dimension assesses the risk of the dependency itself being compromised, rather than merely being vulnerable.
Package provenance: Is the package published from a verified CI/CD pipeline, or from a developer's laptop? Does the package registry support provenance attestations (like npm's Sigstore integration or PyPI's Trusted Publishers)?
Ownership changes: Has the package recently changed maintainers? Ownership transfers are a known attack vector -- an attacker gains control of a popular package and pushes a malicious update.
Typosquatting exposure: Are there packages with confusingly similar names? Typosquatting attacks on npm and PyPI are frequent. A risk intelligence platform should flag when you are using a package that has known typosquat variants.
Build reproducibility: Can the published package be reproduced from its source code? Packages where the published artifact diverges from the source repository are a higher risk.
4. License Risk
License compliance is often treated as a legal concern separate from security, but license risk can have security implications:
Copyleft propagation: GPL and similar licenses require derivative works to be distributed under the same license. Using a GPL-licensed dependency in a proprietary product can create legal exposure that affects the business.
License changes: A dependency that was MIT-licensed may change to a more restrictive license in a new version. If your automated dependency updates do not check for license changes, you could inadvertently introduce license incompatibilities.
Unknown licenses: Some packages have no license declaration, custom licenses, or contradictory license information. These represent unquantifiable legal risk.
License compatibility: Even permissive licenses have compatibility constraints. Combining Apache-2.0 and GPL-2.0-only code, for example, creates a compatibility issue that legal teams need to evaluate.
5. Malicious Package Detection
The fastest-growing risk dimension. Malicious packages published to npm, PyPI, and other registries increased by over 150% in 2024. These are not vulnerabilities in legitimate software -- they are intentionally malicious code designed to steal credentials, install backdoors, or exfiltrate data.
Detection approaches include:
Static analysis: Analyzing package code for suspicious patterns like obfuscated code, dynamic code execution (eval, exec), network calls to unknown domains, or file system access to sensitive paths.
Behavioral analysis: Installing packages in sandboxed environments and monitoring their runtime behavior. Malicious packages often perform their payload during installation (in postinstall scripts or setup.py).
Metadata analysis: Examining package metadata for risk signals: new packages with names similar to popular ones, packages with suspiciously high download counts relative to their age, packages published by accounts with no history.
Community intelligence: Aggregating reports from security researchers, package registry maintainers, and threat intelligence feeds.
Building the Intelligence Layer
Raw risk signals are not intelligence. A list of health metrics, license findings, and vulnerability counts is data. Intelligence is the synthesis of that data into actionable decisions.
An effective risk intelligence platform should answer questions like:
- "Should we adopt this new dependency?" with a comprehensive risk profile, not just a vulnerability count.
- "Which of our existing dependencies pose the highest risk?" considering all five dimensions, not just known CVEs.
- "What changed in our dependency risk profile since last week?" tracking new vulnerabilities, maintainer changes, license modifications, and emerging threats.
- "If this dependency is compromised, what is our blast radius?" understanding which products, services, and data flows depend on it.
Risk Scoring
Combining multiple risk dimensions into a single score is tempting but dangerous if done naively. A dependency with zero known vulnerabilities but a single, inactive maintainer and no security policy is a different kind of risk than a dependency with three medium-severity CVEs but an active, well-funded maintainer team that patches promptly.
Effective risk scoring weights dimensions based on organizational context. An organization that publishes open source software may weight license risk more heavily. An organization in a regulated industry may weight vulnerability management metrics more heavily. A startup moving fast may weight maintainer health most heavily because they need dependencies that will not become liabilities.
Continuous Monitoring
Open source risk is not static. A dependency that was low-risk last month can become high-risk overnight if its maintainer transfers ownership, a critical vulnerability is disclosed, or a malicious version is published.
Continuous monitoring means:
- Re-evaluating risk scores as new data arrives.
- Alerting on significant risk changes (not just new CVEs).
- Tracking trends over time to identify dependencies with deteriorating health.
- Monitoring package registries for ownership changes and suspicious updates.
How Safeguard.sh Helps
Safeguard functions as an open source risk intelligence platform across all five dimensions. Vulnerability scanning is enriched with EPSS and reachability data for prioritization. Dependency health metrics track maintainer activity, project sustainability, and community engagement. License detection and compliance checking integrate with organizational policies. And the platform's continuous monitoring alerts teams to risk changes, not just new CVEs.
The unified dashboard provides a single view of open source risk across an organization's portfolio, enabling security teams to make informed decisions about dependency adoption, prioritization, and remediation. Rather than stitching together separate tools for vulnerability scanning, license compliance, and dependency health, Safeguard provides the integrated risk intelligence that mature open source governance requires.