AnonymousSign in
Every claim is labeled by where it came from and how independently it's been verified. Higher verification means a more independent source — not a better product.
See the labels in use: browse the catalog — every vendor page carries them — or open an RFI/RFP questionnaire, where each criterion is labelled by the same five sources.
Every vendor page shows a Trust Profile instead of a single composite score. That is a deliberate choice, not a missing feature: a single 0–100 number invites exactly the misreading the caveat above warns against, and testing it against this catalog showed it mostly measured how much of a vendor we had managed to scan — not how trustworthy they are. Five separate, named questions replace it:
Each dimension states a plain-English result — Strong, Mixed, Limited, or Not checked — with the evidence behind it and a link to the source. Not checked means we have not looked yet, and is never counted against a vendor — the single rule the whole design rests on. Given how young this catalog is (most profiles are AI-populated from public sources and have not yet been claimed by the vendor), most vendors will honestly read "not checked" on several dimensions today. That is the accurate answer, not a gap to hide.
The Trust Profile appears on every vendor page, and side by side on the compare view for up to four vendors at once.
When you research here, the platform knows who you are (verified by your company email domain), but no vendor sees your identity until you explicitly reveal it — per vendor, and you can withdraw at any time. We say "private," not "anonymous," because behavioral signal in a small category could still narrow who you are.
What you see when you browse and compare is never influenced by vendor spend. Monetization is structurally separated from the comparison and recommendation logic.
We track public security-hygiene signals for every vendor — response headers, DNSSEC, CAA records, trust-center presence, certifications — and cross-reference them against two independent, federally-sourced outcome signals: CISA's Known Exploited Vulnerabilities (KEV) catalog and SEC 8-K material-cybersecurity-incident disclosures. The result is counter-intuitive: across the 29 vendors in our catalog with at least one actively-exploited CVE, every hygiene signal we track is higher, not lower, than the catalog average.
This is not a claim that hygiene doesn't matter, or that any specific vendor is unsafe — it's a reminder that self-reported and publicly-observable hygiene signals are one input, not a substitute for real-world outcome data. Look up a vendor's known CVEs directly rather than inferring safety from surface-level signals alone. (Separately, 2 vendors in our catalog have filed a public SEC 8-K disclosing a material cybersecurity incident.)
We also track whether a vendor maintains a public GitHub organization. Vendors that do get dramatically more CVEs tracked against them — not necessarily because their software is less secure, but because public code gets more independent research, easier public disclosure, and a larger contributor base than closed-source software. A raw CVE count reads very differently once you know whether the vendor even ships public code.
This isn't a claim that open development is riskier — it's a reminder to read CVE counts in context rather than as a bare severity ranking between vendors.
We also track how long each vendor's domain has been registered, as a proxy for how long they've been operating. Vendors with at least one tracked CVE have been registered, on average, more than 1.6x longer than vendors with none — simply having more product-years in the market gives researchers more time to find and disclose vulnerabilities, independent of current security quality.
This isn't a claim that newer vendors are safer — it's a reminder that a raw CVE count reflects time in market as much as it reflects security posture.
Unlike the cross-references above, this one has nothing to do with vulnerabilities. We track two independent, unrelated transparency practices: running a public GitHub organization, and publishing a live incident/uptime status page. Vendors that do one are meaningfully more likely to also do the other — a real pattern in engineering culture, not a coincidence.
This isn't a security or quality signal in either direction — it's a reminder that a vendor's transparency posture is broader than any single practice, security-related or not.
Unlike the cross-references above, this isn't a claim about vendors — it's a claim about us. We publish exactly how recently each of the 9 independently-run signals above was last re-checked against the vendor's own live site, catalog-wide, rather than asking you to trust that a one-time snapshot stays accurate.
100% of 5,659 tracked signal checks catalog-wide were refreshed within the last 30 days:
A signal not yet checked for a given vendor simply isn't counted here — this reports freshness among what has been checked, not full catalog coverage (see each signal's own section on a vendor's page for that).