signal 01deterministic

Verify software before the agent acts on it. One call. Three deterministic signals.

Call Attestd before install, execute, recommend, deploy, expose, or upgrade. CVE risk, supply chain compromise, and package name integrity. No code or repository access required.

risk_stateNVD-derived vulnerability risk classification.

supply_chain.compromisedMalicious publish status, independent of CVE history.

typosquatPackage name integrity: typosquats and AI-hallucinated names.

A package can return risk_state: "none" and supply_chain.compromised: true. The signals are independent by design.

Read the postmortem For Claude Code, Cursor, Windsurf

attestd check

$curl "https://api.attestd.io/v1/check?product=react-codeshift&version=1.0.0" -H "Authorization: Bearer $ATTESTD_API_KEY"

{
  "supported": false,
  "supply_chain_monitored": false,
  "typosquat": {
    "detected": true,
    "kind": "hallucination",
    "resembles": "@types/jscodeshift",
    "likely_intended": [
      "@types/jscodeshift",
      "jscodeshift"
    ],
    "confidence": 0.9,
    "ecosystem": "npm"
  }
}

one call / three signalsrefreshed every 6h

quickstart

# 1. Get a free key at https://api.attestd.io/portal/login
export ATTESTD_KEY=<your-api-key>

# 2. Check a vulnerable component
curl -s "https://api.attestd.io/v1/check?product=log4j&version=2.14.1" \
  -H "Authorization: Bearer $ATTESTD_KEY" | jq

# 3. Check a safe component
curl -s "https://api.attestd.io/v1/check?product=log4j&version=2.25.5" \
  -H "Authorization: Bearer $ATTESTD_KEY" | jq

# 4. risk_state values: critical | high | elevated | low | none

Free tier includes 1,000 calls per month. Attestd has been decommissioned. The examples below are archival.

1,012

cve products

1,000

free calls / mo

29,252

pypi packages

310,740

npm packages

Autonomous systems don't read advisories. Neither should they have to.

AI agents and automated infrastructure are making decisions about software at machine speed: deploying services, patching systems, exposing endpoints. Agents also invent package names. Scanners that only score known packages miss that failure mode entirely.

NVD, CISA KEV, and OSV all publish JSON APIs. The data exists and is machine-readable. What does not exist is a unified, deterministic security condition a system can branch on. NVD records span inconsistent CPE namespaces. CVSS scores require interpretation. KEV requires cross-referencing against version ranges. Multi-source synthesis requires continuous normalization. None of it is directly actionable by a system that needs to branch on a condition. And none of it answers whether the package name itself is real.

What your system needs to know

→Is this version actively exploited right now?
→Can it be exploited without authentication?
→Is there a fixed version available?
→What is the operational risk state?
→Is this package name real, or invented?

What public sources actually give you

×CVE IDs and prose descriptions
×CVSS scores requiring interpretation
×Advisories written for security analysts
×No signal when an agent invents a package name
×No structured answer to any of the above

“Security data exists in machine-readable feeds. It does not exist as a unified, deterministic security condition an autonomous system can reliably act on.”

Raw advisory data in. Structured risk state out.

NVD + CISA KEV + vendor advisories→attestd synthesis pipeline→deterministic risk state

Ingests public sources continuouslyNVD, CISA KEV, and vendor advisories, reconciled and updated every six hours. Your system always queries current data.

Extracts structured factsAdvisory language stripped. Every CVE reduced to typed boolean and categorical fields. No prose. No interpretation required.

Tracks active exploitationWhether a vulnerability is being actively exploited in the wild, not just reported. Sourced directly from CISA KEV.

Returns a single deterministic risk stateOne response per query. Same version always returns the same risk_state given the same underlying data. No probabilistic scoring. No ambiguity.

// important
attestd does not detect vulnerabilities on your systems. It interprets publicly known security conditions for software versions. No scanning. No agents. No data collection.

Use as a deploy gate or a risk signal

Your CI pipeline, automation script, or AI agent calls attestd before any deployment decision. No extra infrastructure. No CVSS math.

python

import os
import attestd

client = attestd.Client(api_key=os.environ["ATTESTD_API_KEY"])
risk = client.check("nginx", "1.20.0")

if risk.risk_state == "critical":
    print("Deployment blocked: actively exploited vulnerability")
    exit(1)

▸

A CI pipeline can automatically prevent deploying actively exploited software. No analyst required.

// note Blocking deploys is one use. Most systems use attestd as a risk signal alongside their own policies.

Everything your system needs to decide. Nothing it has to interpret.

A single API call returns a complete structured assessment. Boolean fields your agent can branch on directly. A deterministic risk_state your pipeline can act on without parsing.

full response

json

{
  "product": "log4j",
  "version": "2.14.1",
  "supported": true,
  "risk_state": "critical",
  "risk_factors": [
    "active_exploitation",
    "remote_code_execution",
    "no_authentication_required",
    "internet_exposed_service",
    "patch_available"
  ],
  "actively_exploited": true,
  "remote_exploitable": true,
  "authentication_required": false,
  "patch_available": true,
  "fixed_version": "2.25.5",
  "confidence": 0.5,
  "cve_ids": [
    "CVE-2021-44228",
    "CVE-2021-44832",
    "CVE-2021-45046",
    "CVE-2021-45105",
    "CVE-2025-68161",
    "CVE-2026-34477",
    "CVE-2026-34479",
    "CVE-2026-34480",
    "CVE-2026-34481",
    "CVE-2026-49844"
  ],
  "cves": null,
  "max_epss": 0.99999,
  "supply_chain": null,
  "supply_chain_monitored": false,
  "typosquat": null,
  "last_updated": "2026-08-13T16:28:06.303403Z"
}

what each field means

risk_stateDeterministic classification: critical | high | elevated | low | none.

risk_factorsReasons for the classification (for example active_exploitation, remote_code_execution, patch_available).

supportedWhether attestd has data for this product. false = unknown product.

authentication_requiredWhether exploitation requires valid credentials. false = unauthenticated exposure.

confidenceSignal confidence (0–1.0) based on source quality and corroboration.

last_updatedWhen the underlying data was refreshed. Pairs with X-Attestd-Knowledge-Age header.

risk_state values

risk_state	meaning
`critical`	actively exploited or remotely exploitable internet-exposed risk
`high`	severe vulnerability with known exploitation potential
`elevated`	meaningful security issue requiring planned remediation
`low`	minor or non-exploitable issue
`none`	no known relevant vulnerabilities

These values are deterministic. The same software version always returns the same risk_state given the same underlying data.

“attestd doesn't replace your system's judgment. It gives your system the structured reality it needs to exercise judgment correctly.”

Verify software before the agent acts on it. Not only at deploy time.

A deploy gate is a single point in a pipeline. It can be bypassed, disabled, or removed. It only fires when something is about to happen.

Attestd belongs at every action boundary: before install, execute, recommend, deploy, expose, or upgrade. Same call. Same fields. Same mental model wherever a system is about to act on software.

Treat it like a DNS resolver for software integrity: a persistent, fast source of structured reality that decisions are built on. A checkpoint is optional. The action-boundary check is the product.

A gate

×Fires once per pipeline run
×Can be bypassed or disabled
×Produces a pass/fail verdict
×Lives in CI configuration

A sensor

→Called at every action boundary
→Before install / execute / recommend / deploy / expose / upgrade
→Returns structured context
→Lives in the system's logic

Autonomous systems are already making infrastructure decisions. The question is whether they make them reliably.

The removal of humans from the critical path of infrastructure decisions is not a future state. Agents are already resolving dependencies, making deployment calls, and managing running services without waiting for a human to approve each step. The trajectory is accelerating. The question is no longer whether machines will make these decisions: whether they will make the same correct decision every time they encounter the same condition.

LLMs are capable of sophisticated reasoning, but they do not produce consistent outputs from inconsistent inputs. Ask any model to assess whether a given version is safe to deploy. You will get a different answer depending on how the question is framed, what context is in the prompt, and whether the model happens to retrieve current exploitation data. That is not a model quality problem. It is an input quality problem. NVD, CISA KEV, and OSV all publish structured JSON feeds. None of them provide a precomputed synthesis into a single, bounded security condition. CPE namespace normalization, CVSS interpretation, KEV cross-referencing, and multi-source conflict resolution happen differently on every query. The same software version produces a different assessment on different runs. You cannot build reliable autonomous systems on top of non-deterministic synthesis of disparate feeds.

Deterministic structured security inputs are not an optimization of the current pipeline. They are the prerequisite for the trustworthy autonomous future. If you want a machine to make the same correct decision every time it encounters the same security condition, it needs to receive that condition as a precomputed fact, not synthesized from disparate feeds on every call. attestd is that layer. The API does not exist to save developers time. It exists because reliable autonomous decision-making requires it.

Read the full argument →

attestd for developers

Verify before install or recommend. Inside your IDE.

Connect Cursor, Claude Code, or Windsurf to Attestd via MCP. Before your assistant installs a package or recommends a dependency, get a structured answer without leaving the editor.

Attestd for Developers →

NVD describes vulnerabilities. attestd describes operational risk state.

Querying NVD directly gives you CVE IDs, CVSS scores, and prose descriptions. That data is accurate and comprehensive. It is not a unified, deterministic security condition. To turn it into something a system can branch on, you need to parse CVSS vectors, cross-reference KEV feeds, normalize version ranges across inconsistent CPE namespaces, handle multi-range CVEs, filter sentinel records, and synthesize conflicting data from multiple sources.

attestd does that work once, continuously, for every supported product. Your system asks one question and gets a structured answer. It also aggregates EPSS scores daily, so each response includes the exploitation probability for the next 30 days alongside the structural risk classification.

the difference

NVD direct

CVE-2021-44228
CVSS: 10.0
Description: Apache Log4j2 2.0-beta9 through 2.15.0...
[847 words of prose advisory]

Requires parsing CVSS, reading prose, and cross-referencing KEV before an automated system can form a conclusion.

attestdmachine-readable

{
  "risk_state": "critical",
  "actively_exploited": true,
  "remote_exploitable": true,
  "authentication_required": false,
  "patch_available": true,
  "fixed_version": "2.25.5",
  "max_epss": 0.99999
}

No parsing. No cross-referencing. No interpretation.

Live coverage and ledger velocity.

Figures track the production API and the public detection ledger. CVE product coverage is 1,012 and climbing as the ingestion pipeline expands.

29,252 PyPI · 310,740 npm

37,816

Detection ledger entries

public commit trail

every 6 hours

NVD / KEV ingest

scheduled NVD and CISA KEV cycle

90.44%

Uptime

api.attestd.io

CVE and package counts from the last GET /v1/coverage snapshot. Ledger and uptime refresh about once per day. X-Attestd-Knowledge-Age on each API response is elapsed time since that product's last synthesis, not the last NVD or KEV ingest.

Infrastructure CVE coverage, supply chain monitoring, and package name integrity.

1,012 infrastructure products with NVD-backed CVE data (77 with detailed docs), plus 29,252 PyPI and 310,740 npm packages checked for malicious publishes. Name integrity flags typosquats and AI-hallucinated package names. Three independent security signals in a single API call.

Apache Cassandra Apache CouchDB Apache Derby Couchbase Server Elasticsearch MariaDB Microsoft SQL Server MongoDB MySQL Oracle Database PostgreSQL Redis SQLite Apache HTTP Server Caddy HAProxy

and 996 more. View full API catalog

Supply chain monitoring: 29,252 PyPI and 310,740 npm packages. View the full list.

CVE coverage expands based on demand. Email [email protected] to request infrastructure products or additional PyPI / npm packages.

How attestd works

sourcessynthesizes public vulnerability sourcesNVD, CISA KEV, exploit databases, and security advisories, continuously ingested and reconciled.

pipelinestructured extraction pipelineEach advisory goes through a structured extraction process to produce consistent, typed fields.

rulesdeterministic classification rulesClassification rules with defined logic produce repeatable results. There is no ML scoring at query time.

datacontinuously updated datasetThe dataset reflects the current state of exploitation activity, not a static snapshot.

LLMs may assist structured extraction during ingestion. They do not score or generate answers at query time. risk_state is produced by deterministic rules over the stored normalized state. Supporting evidence can include confidence and EPSS. Those fields do not decide risk_state.

⚠ attestd reports observed operational risk signals. It does not guarantee safety. Always apply contextual judgement alongside attestd data.

Every response includes an X-Attestd-Knowledge-Age header showing how recently the underlying data was refreshed. Live uptime and incident history at status.attestd.io.