Frequently Asked Questions
How fresh is the data?
On V1 (post-launch): the NVD feed and CISA KEV catalog are ingested every 6 hours. Responses are cached in memory for up to 1 hour. The X-Attestd-Knowledge-Age response header shows elapsed time since the last synthesis run. During the current alpha, the live demo key serves seed data from February 2026 — the 6-hour ingestion cycle is not yet active. After DNS cutover to V1, freshness semantics described here will apply.
What does confidence: 0.5 mean?
A confidence score of 0.5 indicates the risk assessment is based on database-derived fields (NVD CVSS metadata) rather than LLM-extracted facts. The risk_state is still correct — it reflects the worst-case from available data — but the supporting detail (remote_exploitable, authentication_required, etc.) was inferred from CVSS vectors rather than synthesized from full CVE text. A score ≥ 0.7 means LLM extraction succeeded with high corroboration.
A product returned supported: false. Does that mean it's safe?
No. supported: false means attestd has no vulnerability data for that product — not that it has no vulnerabilities. Treat it as unknown risk. The correct response is an explicit policy decision: block (safest), warn with operator notification, or skip with documented justification. Never infer safety from the absence of attestd data.
Can I use the demo key in production?
No. The demo key (attestd_demo_key) is rate-limited to 60 requests/minute with no monthly allocation. It's suitable for development and evaluation only. Get a production key from the developer portal.
Why does the same product+version sometimes return different CVE IDs?
CVE data is updated continuously. New CVEs are published, existing CVEs are revised, and CISA KEV additions change the actively_exploited flag. The data is refreshed every 6 hours so the response for a given version may change as new vulnerabilities are discovered or existing ones are revised.
What is authentication_required: false actually telling me?
It means at least one CVE affecting the queried version has an unauthenticated attack path — an attacker does not need valid credentials to exploit it. The field uses conservative (all-false) aggregation: if any CVE in the matching ranges is unauthenticated, the field is false. This reflects real-world risk: a single unauthenticated exploit path is sufficient for an attacker.
How does version matching work?
Attestd compares the queried version against the affected version ranges stored for each CVE. Standard semantic versioning (major.minor.patch) is used. Non-standard suffixes like OpenSSH's p-suffixes (e.g. 9.8p1) are normalised before comparison. If the version string cannot be parsed, the API returns HTTP 422.
What happens when multiple CVE ranges match the queried version?
Results are merged using worst-case semantics: highest risk_state, any() for boolean risk factors (except authentication_required which uses all()), minimum confidence, and union of cve_ids. See the Response Field Reference aggregation section for full details.
Is there an SLA for data accuracy?
Attestd is currently in private alpha and does not carry a formal accuracy SLA. Risk assessments are derived from NVD CVE data and CISA KEV; the quality of attestd's output is bounded by the quality and completeness of those sources. Confirmed inaccuracies can be reported to support@attestd.io.
Can I request coverage for a product not in the current list?
Yes. Coverage expands based on early-access user requests. Use the early access form on the homepage and describe what you need. Products with high sentinel rates (CVEs that lack version data) are excluded from the default set, but may be added as data quality improves.
Still have a question? support@attestd.io