Look twice.Find the gem.

AI agents and MCP servers, each published with its source and what the checks found.

Marketplace

  • Everything
  • AI agents
  • Apps
  • MCP servers
  • Templates
  • What people want
  • What changed this week
  • The verification standard
  • The ooruby Index
  • Servers that publish no source
  • Reliability guides
  • What the catalogue holds
  • Sell here

Our library

  • Everything, in one place
  • Guides
  • Glossary
  • Calculators
  • Checklists and cheat sheets
  • Community

ooruby

  • Home
  • For teams
  • Site status
  • Company projects
  • RSS feed

Verification records what our published tests found on a specific version at a specific date. It is not a warranty, and it does not certify that software is free of defects.

Rubricv1.0
AI agentsAppsMCP serversTemplatesWantedCommunityOur library
Sign inSell
Back to the standard
rubric v1.0

Dependency advisories

Known vulnerable dependency versions, with severity and whether the affected path is reachable.

Applies to
agents, MCP servers, apps, templates
Standard references
CWE-1395

A finding here is not a failure

Software of any size carries something. A listing that raises findings on this check is still sold, with the findings published and their severity and reachability stated. A badge that only ever said pass would teach people to stop reading it.

Explainer · 2026-09-30

Dependency advisories: what a known-vulnerable dependency does and does not mean

Most of the code in a package is somebody else's. An advisory against one of those dependencies is a fact worth knowing, and on its own it says nothing about whether the vulnerable code is ever reached.

What this row checks

Known-vulnerable dependency versions, with their severity and, where it can be determined, whether the affected code path is reachable. Advisories come from public databases such as the GitHub Advisory Database and OSV, matched against the versions a package actually resolves to.

Why severity alone overstates it

An advisory describes a flaw in a function. If the package never calls that function, or never passes it input an attacker controls, the flaw is present and unreachable. Printing a critical severity beside a package for a function it never touches trains readers to ignore the column.

The opposite mistake is worse: a moderate advisory on a path the package uses on every request. Reachability is the question that separates the two, and it takes reading the code that calls the dependency.

What the catalogue does today

Every night the catalogue checks the advisories published against each package itself, and a malware advisory is shown as its own sentence, above everything else on the page. Matching the full resolved dependency tree against an advisory database is not done for catalogue listings, and the published evidence map says so: for a package read as text, this row is only partly answerable.

Sources

  1. CWE-1395: Dependency on Vulnerable Third-Party Component
  2. GitHub Advisory Database
  3. OSV: Open Source Vulnerabilities
  4. ooruby: what each kind of evidence can answer

In the glossary: CVE, Supply chain attack.

What this check has found

Nothing in the catalogue has raised a finding on this check. That is a fact about what has been tested so far rather than a guarantee about what is out there, and it is printed because a check that never fires is worth knowing about too.

Other checks

No shipped credentialsBehaviour matches the manifestDeclared egressData handling disclosedLicence and provenanceTransparency self-certification

Every listing in the catalogue shows its result on this check, with the findings summarised in public and the full report to whoever bought it. Open the catalogue.