faq

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, Pro at $79/mo, and Team at $299/mo) include higher included call volumes and overage billing rather than hard caps.

How many products and packages does Attestd cover?

Attestd covers 72 CVE-backed infrastructure products (databases, web servers, Kubernetes components, CI/CD platforms, language runtimes, and more) plus 52 PyPI and 70 npm packages for supply chain monitoring. See the Products and Supply Chain docs for the full lists and API slugs.

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. The confidence field signals how reliable the supporting detail fields are for a given response. For a full explanation of what drives each tier, see Why Attestd. Confirmed inaccuracies can be reported to [email protected].

Can I request coverage for a product not in the current list?

Yes. Coverage expands based on demand. Email [email protected] 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.

What does supply_chain.compromised: true mean?

A verified malicious publish was detected for that package version via OSV advisories, PyPI security yanks, npm deprecation signals, or the Attestd registry. Treat it as an incident signal - do not deploy, do not upgrade automatically. The compromised_at and removed_at timestamps indicate when the malicious version appeared and when it was pulled from the registry.

How often is supply chain data updated?

Ingestion runs on a scheduled basis. The last_updated field in the response shows when monitoring last ran for that package. Registry and OSV sources are checked on each run. The 52 PyPI and 70 npm packages on the watchlist are checked continuously as part of the supply chain monitoring cycle.

Can I use supply chain data to gate deployments?

Yes. Check the supply_chain.compromised flag in your deployment script or CI pipeline. If true, block the deployment. A false value with an empty sources array means no known compromise was found at last ingestion.

Still have a question? [email protected]