Source Model
Each record combines upstream open source health signals, public security data, and an
enterprise exposure overlay. Source cards stay visible so every score can be traced back to
the collector or static input that produced it.
Library scopeFINOS OSERA backpatch repos, package coordinates, upstream repositories.
CollectorsGitHub API, OpenSSF Scorecard, deps.dev, npm, OSV, CISA KEV.
Score modelNormalize evidence into vitality dimensions and source confidence.
Browser overlayJoin Risk Navigator collections for internal exposure and prioritization.
- OpenSSF Scorecard supplies security posture checks and direct links to the Scorecard viewer.
- GitHub API metadata supplies activity, releases, contributors, issue, and pull request signals.
- deps.dev and npm downloads supply package registry health where the ecosystem supports it.
- OSV supplies package vulnerability records; CISA KEV matches are derived from OSV CVE aliases.
- FINOS OSERA backpatch metadata links each focused library to its OSERA fork and upstream repository.
- Risk Navigator collections provide enterprise exposure by matching package coordinates from the selected dataset.
OSS Vitality Weights
The browser computes OSS vitality as a weighted blend of five dimensions.
25%Project vitality
25%Security health
20%Sustainability and governance
15%Dependency hygiene
15%Ecosystem resilience
Enterprise priority then starts from the health gap, amplifies it by ecosystem criticality,
internal application exposure, deployed-version risk, and source confidence.
What The Vitality Terms Mean
Project vitality
Looks for recent project motion: commits, releases or tags, recent pushes, issue activity,
and contributor activity. These metrics come primarily from the GitHub API and indicate
whether the upstream is still moving.
Security health
Looks for security process and vulnerability posture: OpenSSF Scorecard checks such as
maintained status, branch protection, code review, dependency update tooling, pinned
dependencies, SAST, security policy, signed releases, and vulnerability checks, plus OSV
package vulnerability records and CISA KEV matches.
Sustainability and governance
Looks for maintainership and governance signals: contributor depth, review flow, licensing,
security policy presence, CII best-practices signal where Scorecard reports it, issue/PR
response indicators, and whether the repository appears active or archived. These come from
OpenSSF Scorecard and GitHub-derived CHAOSS-style metrics.
Dependency hygiene
Looks for package maintenance and dependency-management health: latest/default version,
release age, deprecated versions, Scorecard dependency update tooling, pinned dependency
checks, and package vulnerability checks. These come from deps.dev, npm where relevant,
and OpenSSF Scorecard.
Ecosystem resilience
Looks for how widely used and resilient the package appears to be: dependent counts,
download signal where available, stars/forks, contributor base, and recent activity.
These metrics come from deps.dev, npm downloads, and GitHub metadata. It is a proxy for
ecosystem importance and support capacity, not a guarantee of safety.
CHAOSS-Derived Health
The CHAOSS card is not a separate external score. It visualizes GitHub-derived maintainership
and flow indicators: contributor depth, commit velocity, issue closure, pull request merge
ratio, and median merge latency. These are health indicators used to interpret undermaintenance
pressure, not proof of project quality by themselves.
Undermaintenance Pressure
Undermaintenance pressure is a derived triage signal, not a headline score. It compares
downstream demand against observed maintainer capacity: package dependents, npm download signal
where available, and internal application usage increase demand; active maintainers and recent
contributors increase capacity. Higher values mean many consumers appear to depend on a project
relative to the visible maintainer/contributor base. It is useful for finding projects that may
need stewardship, backpatch attention, or deeper review, but it is not currently a table column.
The default grid sort is OSS vitality ascending, so weaker upstream health appears first.
Not Applicable Versus Error
Muted source cards mean the package coordinate does not apply to that collector. For example,
generic system packages such as system/openssl need distro-specific OSV ecosystems
such as Debian/openssl, Ubuntu/openssl, or
AlmaLinux/openssl. A muted OSV card is therefore a coordinate-scope signal, not a
vulnerability clean bill of health.
