Frequently Asked Questions
How fresh is the data?
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 for the queried product.
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.
Is there a free tier?
Yes. The free tier includes 1,000 API calls per month at no cost — no credit card required. Sign up at api.attestd.io/portal/login to get your key. Paid plans (Starter at $19/mo and Pro at $79/mo) include higher included call volumes and overage billing rather than hard caps.
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 does not currently 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 demand. Email support@attestd.io with the product name and your use case. 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