How Securaity works

Securaity’s advisories come from 3 public vulnerability sources, which we check every day. Severity comes from the score the source publishes, and the source’s description is quoted, not rewritten. Everything else on the site (analyses, tool profiles, guides) is built from stated sources and checked against fixed rules before it goes live. This page explains each step so you can judge how far to trust what you read here.

Where advisories come from

Every day, Securaity pulls new and changed vulnerability records for 30 tracked AI products from 3 public sources:

• NVD CVE API. Records are matched by the product’s CPE identifier. Two tracked products have no CPE entry. For those, a record matches when an exact product phrase appears near the start of its description.
• GitHub Advisory Database. Records are matched by package name in the pip, npm and Go ecosystems.
• CISA Known Exploited Vulnerabilities catalog. This sets the “known exploited” flag on an advisory.

We publish 1 advisory per vulnerability record and product. Advisory ids follow the pattern SA-YY-NNN: the year, then a running number. Numbers are assigned in the order the source first published the records.

A few rules control what appears:

• The source description is quoted verbatim and attributed. Securaity does not rewrite it.
• New advisories are created only for records the source first published within the last 180 days. Older records are updated only if Securaity already carries them.
• If a source withdraws or rejects a record, we mark the advisory withdrawn and remove it from the public lists.
• Each daily run is all-or-nothing. If any of the 3 sources cannot be fetched, nothing is written and the previous day’s data stays in place. You will never see a half-updated set of advisories.

How severity is rated

Severity follows the CVSS base score the source publishes. We do not assign our own score.

Severity	CVSS base score
Critical	9.0 and above
High	7.0 to 8.9
Medium	4.0 to 6.9
Low	Above 0 and below 4.0
Info	No score published

When no score is published, the advisory is rated Info. In that case, if GitHub has a reviewed severity label for the record, we use that label.

What the dates mean

Every advisory shows 2 kinds of dates, each with its own label:

• When Securaity published the advisory and when we last updated it.
• When the source first published its record and when the source last modified it.

The 2 are never mixed. This matters when you work out how long a problem has been public: use the source dates for that, not ours.

Across the whole site, every “Published” and “Updated” date means when Securaity last changed that page. A CVE’s own dates always appear as source facts with separate labels.

How analyses are written and checked

Critical and High advisories get a short “Who is affected” and “What to do” block. An AI model drafts it from the stored record only: the description, score, product and fix information in that record. The drafting rules forbid adding versions, exploit claims or mitigations the record does not contain.

Each draft is then checked by automated rules and reviewed before it is stored. The block states the date of the source record it was written from. If the source later changes its record, you can see whether the analysis predates that change.

A new advisory shows facts only until an analysis run adds the block. If you see a Critical or High advisory without one, the analysis has not been written yet.

Product pages and the five-record rule

Each tracked product has 1 page that lists its advisories, newest first, with an RSS feed. You can add that feed to a reader to follow the products your organization uses.

A product page stays out of search engine indexes and the sitemap until it has at least 5 advisories. This keeps thin pages from competing with the original sources in search results. The page still exists and still works before it reaches 5.

How tool profiles are verified

Each tool safety profile is built from the vendor’s own published pages, such as the privacy notice, the data-usage or training FAQ, and the enterprise or trust page. Those pages are fetched on a stated date.

Each profile covers these fields:

• Whether it trains on your data by default
• How to opt out
• Data retention
• Admin controls
• Certifications
• Data region
• Differences between free and paid tiers
• A verdict for a non-profit handling donor data

If the vendor’s pages do not cover a field, the profile marks it “not documented” and does not fill it in. Treat “not documented” as a question to put to the vendor before you rely on the tool. Every profile shows a “Verified on” date and links to the pages used, so you can check whether the vendor has changed them since.

How the course, guides, glossary and blog are produced

These pages are drafted with the help of an AI model, working from a brief of verified facts and sources. Each draft is then reviewed against the site’s rules: no invented statistics or sources, and no vendor claims that do not appear on the vendor’s own pages. Each page shows when Securaity published it and when we last updated it.

Corrections

If you find an error, send it by email through the contact page. Corrections that include a link to the source are handled first, because we can check them against the record directly.