How ShipWatch Scores Your Dependencies (And Why You Should Trust It)

Security teams do not need another raw vulnerability feed. They need a prioritization signal that is consistent, explainable, and tied to real-world risk.

ShipWatch combines security severity with maintenance and ecosystem signals so teams can answer a simple question: which dependencies require attention right now, and which can wait.

This is a scoring system designed for decisions, not just for dashboards.

Security is anchored in CVSS because it is the industry standard for severity. We use CVSS where available and contextualize it with vulnerability counts and exploitability signals.

A package with multiple high-severity CVEs should not be treated the same as a package with a single low-severity advisory. The score reflects that difference.

The goal is to make severity comparable across packages so teams can triage quickly.

Maintenance signals capture the health of the project itself. A package with no commits in a year, a single maintainer, or a large backlog of issues is a risk even if it has no CVEs today.

This is why ShipWatch uses last commit time, maintainer count, and issue volume as inputs. These signals show whether a project can respond when a vulnerability appears.

It is not about punishing small projects. It is about being honest about operational risk.

Ecosystem health matters. A deprecated package with low downloads is more likely to become a liability than a widely adopted, actively maintained library.

ShipWatch tracks signals like downloads, deprecation flags, and license clarity. These are practical indicators of whether a dependency is healthy enough to trust.

The result is a score that reflects both the risk of exploitation and the risk of abandonment.

A good score is not just a number. It is an explanation. ShipWatch surfaces the factors behind each score so teams can validate the signal before acting.

This transparency helps engineering leaders trust the output. It also helps teams justify remediation work when planning sprints.

Ultimately, the score is a decision aid. It reduces noise and aligns security with engineering priorities.

Use consistent scoring to avoid subjective debates about what to fix first.

Combine security, maintenance, and ecosystem signals to build a more complete risk view.

Explain the score so teams can trust it and act quickly.