Front page
methodology

How we work.

Where the CVE data comes from, how each CVE is tied to a component and which CVE pages search engines see; then how we compare agents, from their own documentation, and the security checklist we walk.

The CVE tracker

Every 6 hours the site pulls NIST NVD for the CVEs of the 20 components it tracks, by their exact CPE names, and checks CISA's Known Exploited Vulnerabilities catalog. A CVE is counted under a component when NVD files it under that component's CPE, or, while NVD has not analysed it yet, when the advisory names the component as the affected product. A tool that only mentions a component is listed apart and never counted.

Affected versions come from NVD's CPE ranges, the CVE record written by the CNA and GitHub's reviewed advisories. Where they disagree, the CVE page says which one it follows and why. The StackScanner compares the versions you paste with those ranges.

Every CVE has a page, but most of them repeat NVD. A CVE page is offered to search engines only when it gives more than NVD's own page: the CVE is about one of the tracked components and names the package; the affected and fixed versions come from a GitHub-reviewed advisory or from the CVE record, and no other source contradicts them; and NVD lists no versions for the component yet, or lists different ones, or one of our breakdowns analyses the CVE. The other pages stay readable from the tracker, marked noindex and left out of the sitemap.

How we compare agents

We do not benchmark agents. An agent page or a comparison is written from the project's own record: its documentation, its code at a named release, its security policy and its advisories. Each fact links to the page it was read on, with the date. Where a page gives a verdict, it is our opinion and says so. No agent has been installed and scored for the site; if one is, the logs will be published with the result.

The security checklist

For every agent we cover, we look for the answer to these questions in its documentation and code. Not every item applies to every agent, and a page says when the documentation is silent.

  • Is the dashboard or gateway authenticated by default?
  • Does it check the origin of WebSocket connections?
  • Does it bind to localhost or to every interface by default?
  • Are tools sandboxed by default, and with what?
  • Is there an approval step for tool calls?
  • How are credentials stored: plaintext, encrypted, OS keyring?
  • Can network egress be restricted to an allowlist?
  • Which paths can the file tools read and write?
  • Are plugins or MCP servers verified before they load?
  • Is there an audit log of tool calls?
  • Is there a security policy, a contact, and a stated response time?
  • How fast were its past CVEs fixed? (The CVE tracker shows it.)

What we do not do

  • Penetration tests. We read the threat model, the defaults and the advisories. We are not a red team.
  • Performance benchmarks. Hardware pages give the manufacturers' figures and published measurements, each linked; an estimate is labelled as one.
  • Cost at scale. The calculators work from published prices and your inputs. Your bill depends on your workload.

Disagreements welcome

If a CVE page shows the wrong versions, an agent page misreads its documentation, or a check is missing from the list, email [email protected] with the source. Corrections are dated on the page they fix.

Related: 2026 landscape report, comparisons, disclosure.