Your autonomous systems are making infrastructure decisions. Give them the security context to make them correctly.

attestd converts public vulnerability data into deterministic, machine-readable risk signals. One API call. Structured facts your system can branch on without interpretation.

CVE risk signals plus supply chain integrity for PyPI and npm packages. Infrastructure security and package provenance in one platform.

Get your free API key Read the docs

Already have a key? Sign in

terminal

try it in 30 seconds

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=nginx&version=1.24.2" \
  -H "Authorization: Bearer $ATTESTD_KEY" | jq

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

Free tier includes 1,000 calls per month. Sign up at api.attestd.io/portal/login. No credit card required.

the problem

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. The security data they need to make those decisions safely exists. It's just not structured for machines.

NVD returns prose advisories written for human analysts. CVSS scores require interpretation. KEV feeds require cross-referencing. None of it is directly actionable by a system that needs to branch on a condition, not read a paragraph.

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?

What public sources actually give you

×CVE IDs and prose descriptions
×CVSS scores requiring interpretation
×Advisories written for security analysts
×No structured answer to any of the above

“Security knowledge exists. It isn't machine-readable. attestd is the translation layer.”

how it works

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.

practical example

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

from attestd import check

risk = 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.

the response

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.17.1",
  "confidence": 0.94,
  "cve_ids": ["CVE-2021-44228", "CVE-2021-45046", "CVE-2021-45105"],
  "last_updated": "2026-02-23T18:21:30Z"
}

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.”

architecture

A security perception layer. Not a checkpoint.

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.

A security perception layer is part of how a system understands the world. attestd is designed to be called anywhere a system needs to reason about software risk: not only before a deploy, but before any decision where the safety of a component is relevant context.

The systems that get the most value from attestd don't use it as a gate. They use it the way they use a DNS resolver: a persistent, fast, reliable source of structured reality that their decisions are built on top of.

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 any decision point
→Part of the system's perception
→Returns structured context
→Lives in the system's logic

the prerequisite

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. Security advisories, CVSS descriptions, and KEV feeds are written for human analysts. They are prose. Prose interpreted differently on different runs produces different decisions. You cannot build trustworthy autonomous systems on top of non-deterministic interpretation of unstructured data.

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 fact, not reconstructed from prose. 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 →

use cases

Built for systems that make decisions, not just pipelines that run checks.

attestd sits wherever your systems make decisions about software.

AI Agents→

Give autonomous systems ground truth

Agents making deployment, patching, or dependency decisions need reliable security context. attestd returns structured facts about CVE risk and supply chain integrity for Python packages like LangChain and LiteLLM.

risk.risk_state, risk.supply_chain.compromised

Infrastructure Automation→

Know before you expose

Before a system exposes a service to the internet, it should know whether that software has known active exploits. attestd answers that question in a single call.

risk.actively_exploited == True

CI/CD Pipelines→

Stop deploying actively exploited software

Add a single check to your pipeline. If the component is actively exploited or a dependency is compromised, the build fails. No analyst required.

if risk.risk_state == "critical" or risk.supply_chain.compromised: exit(1)

Security Tools→

Add operational context without building the pipeline

Enrich your tool's output with real exploitation signals and supply chain integrity data, not just CVSS numbers, without maintaining your own vulnerability intelligence pipeline.

risk.actively_exploited, risk.remote_exploitable

why not just NVD?

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 also written for human analysts, not automated systems.

To turn NVD data into a decision your system can act 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.

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.17.1"
}

No parsing. No cross-referencing. No interpretation.

coverage

Infrastructure CVE coverage + Python and npm supply chain monitoring.

72 infrastructure products with high-quality NVD-backed CVE data, plus 52 PyPI and 70 npm packages checked for malicious publishes. Two independent security signals in a single API call.

Supply chain monitoring: 52 PyPI and 70 npm packages (AI/ML, JS frameworks, TanStack ecosystem, security tooling, and more). View the full list.

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

how the data stays current

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 rulesNo ML scoring. No probabilities. Classification rules with defined logic produce repeatable results.

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

⚠ 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.

when to call attestd

Called at decision points, not just pipeline steps.

attestd is called at decision points: moments where a system is about to change something and needs to know if the software involved is currently safe.

▸Before an AI agent performs any action involving software state

▸Before deploying a service to production

▸Before exposing a port to the internet

▸Before auto-patching a fleet

▸Before upgrading a dependency in an automated workflow

▸Before an autonomous system makes a change it cannot easily reverse

start building

The free tier is live. No waitlist, no approval.

1,000 API calls per month at no cost. No credit card required. Sign up with your email and make your first call in under two minutes.

Free tier
1,000 API calls per month. No credit card required.
72 CVE-covered products, expanding each quarter. See all products in the docs.

Get your free API key →