Stack health
A summary of recorded vulnerabilities, support dates, freshness and version certainty. It does not measure confirmed exploitability.
The score
Every app starts at 100 and loses points from four factors below, with caps and integer rounding. The score is recomputed after successful upload processing, and a snapshot is kept once a day so a digest can show how it moved.
Grades
| Grade | Score | What it means |
|---|---|---|
| A | 90 to 100 | Few score penalties. Review findings and coverage limits. |
| B | 75 to 89 | Some score penalties. Review the factors below. |
| C | 55 to 74 | Several score penalties. Review findings and supported versions. |
| D | 30 to 54 | Large score penalties. Prioritise the findings below. |
| E | 0 to 29 | Very large score penalties. Check the factors and available fixes. |
What moves it
Vulnerability severity
Open vulnerability alerts, weighted by severity and whether a fix exists. Exploited advisories weigh the most.
End of life and approaching end of life
A runtime past its end-of-life date costs the most; one approaching within six months costs less.
Version freshness
How many months behind the latest release your direct dependencies sit, using the median.
Unresolved versions
Components where the version came from a range rather than a lockfile, so the installed version still needs verification.
News and dev tooling do not count
Rank actions using the actual model
The findings command and upload report show factor penalties and recommended actions ranked by estimated score gain. Estimates use the same scoring caps and rounding, removing a package’s scored alerts while holding other inputs unchanged. They are independent and cannot be added together. Fixing a serious issue can earn zero points while a cap still applies.
End-of-life and unresolved estimates describe clearing the whole factor. Freshness has no numeric action estimate. Pending or unavailable scores remain unknown. Keep security risk separate from score gain. See scan results and agent access.
Freshness
For each direct dependency, VibeBeacon checks the latest published version on its registry (npm, PyPI, crates.io, Go modules, RubyGems, Packagist) and shows the latest version, refreshed roughly once a day per component. Months behind is calculated only when both release dates are known. Missing dates mean unknown age and no freshness penalty. A component more than 24 months behind is called out on the app page and on the fix plan.
Where you see it
- A badge on the app detail page, the dashboard cards, and the apps list.
- A “Lowest score” callout on the dashboard for any app graded D or E.
- A line in every digest: the current score and grade, how it changed since the last digest, and the top cause if it moved.
- An app with no manifest yet, or that is not active, shows “Not scored yet” rather than a number.
See also
The fix plan bands that drive most of the vulnerability factor are covered on Fixing an alert.