private alpha

Before your software deploys, ask if it's dangerous.

attestd turns security advisories and exploit activity into structured signals automation and AI systems can safely act on.

get early access how it works

terminal

try it in 30 seconds

quickstart

# 1. Set the demo key (no signup required)
export ATTESTD_KEY=attestd_demo_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

The demo key provides read-only access to a small set of real components. Request early access for full coverage.

the problem

Automation can act. It can't judge.

Modern systems move fast — but speed without security context is compounding risk at machine scale.

✓ your system can

[ok]deploy infrastructure automatically
[ok]patch servers without human review
[ok]expose services directly to the internet

✗ your system cannot

[err]evaluate real-world exploitation status
[err]distinguish a theoretical CVE from an active exploit
[err]translate CVSS scores into operational decisions

Automation failures are often not logic errors — they are context errors.

“Security knowledge exists — but it isn't machine readable.”

how it works

attestd makes security operational

Vulnerability databases describe issues. Systems need to understand risk conditions. attestd bridges that gap.

Human advisories→attestd→automation decisions

correlates vulnerability databasesIngests NVD, CISA KEV, and other public sources to build a unified picture of each software version.

extracts structured factsStrips away advisory language and converts raw data into deterministic boolean and categorical fields.

tracks active exploitation signalsMonitors whether a vulnerability is being actively exploited in the wild — not just reported.

returns deterministic risk stateEvery query returns the same answer given the same inputs. 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.24.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.

why not just CVEs?

CVE records describe what exists. Automation needs to know what matters right now.

NVD / OSVdescribes the vulnerability

attestddescribes the operational risk state

A CVE ID tells you a vulnerability was assigned a number. Querying NVD gives you CVSS scores and prose advisories — data written for human analysts, not automated systems.

Automation needs answers to questions NVD doesn't ask:

→

Is it remotely exploitable?remotely_exploitable

→

Is it actively exploited right now?actively_exploited

→

Does exposure matter for this component?internet_exposed_relevance

→

Is a fix available and what version?patch_available

attestd synthesizes those signals into machine-readable state so your systems don't need to interpret advisories themselves.

not just a deploy check

Your system gets context. Not a verdict.

You can use attestd to block a deployment — but that's just the simplest use. What attestd actually returns is a structured description of the current security reality of a component. The decision belongs to the caller.

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,
  "last_updated": "2026-02-23T18:21:30Z"
}

what each field means

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

risk_factorsReasons for the classification — e.g. 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 tell your system what to do — it gives your system enough structured reality to decide safely.”

built for automated systems

Human analysts read advisories. Machines need structured signals.

AI agents and automated infrastructure cannot reliably interpret security bulletins. They hallucinate context, miss nuance, and produce inconsistent results.

LLMs cannot reliably interpret security bulletins — but they can reliably reason over structured signals.

Human analysts

reads:security advisories

slow, unscalable, requires interpretation

Automation & AI agents

reads:structured signals

fast, deterministic, composable

the difference in practice

CVE recordopaque

CVE-2023-44487

Requires parsing CVSS, reading NVD prose, cross-referencing exploit databases — before an automated system can form a conclusion.

attestd responsemachine-readable

risk_state: "critical"
risk_factors: ["active_exploitation", "remote_code_execution"]
authentication_required: false

No parsing. No interpretation. The system receives structured facts and decides immediately.

the architecture distinction

A gatecan be bypassed, ignored, or removed.

A sensorbecomes part of a system's perception.

attestd is designed to be a persistent security perception layer — not a one-time check that ships with your CI configuration.

use cases

Designed to fit naturally into CI, automation, and agent workflows

attestd sits wherever your systems make decisions about software.

CI/CD→

Stop deploying vulnerable services

Add a single check to your pipeline. If the dependency is actively exploited, the build fails. Before it reaches production.

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

Infrastructure→

Warn before exposing unsafe systems

Know whether the software you're about to deploy to a public endpoint has known active exploits before it faces the internet.

curl api.attestd.io/v1/check?product=...

Security Tools→

Add vulnerability context without a research team

Enrich your tool's output with real operational signals — not just CVSS numbers — without building your own intel pipeline.

risk.actively_exploited == True

AI Agents→

Give autonomous systems a reliable safety signal

Agents making deployment or dependency decisions need ground truth, not heuristics. attestd returns deterministic risk state.

risk.risk_state → "critical" | "high" | "none"

initial coverage

Supported software

attestd currently focuses on internet-exposed infrastructure components. We intentionally support a small set reliably rather than broad coverage unreliably.

log4jnginxApache HTTPDOpenSSHMicrosoft ExchangeVMware ESXiWordPressPostgreSQLRedismore in development

Coverage expands based on what early-access users are building with. Request access and tell us what you need.

transparency

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.

when to call attestd

Concrete integration triggers

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 deploying a serviceCI/CD, GitOps, deploy scripts

▸

before exposing a port publiclyinfrastructure automation, cloud provisioning

▸

before upgrading a dependencypackage managers, Dependabot alternatives

▸

before auto-patching a serverpatch management, fleet orchestration

▸

before an AI agent performs a risky changeautonomous agents, LLM tool use

private alpha

Request API access

attestd is currently in private alpha. We're working with early builders of automation, DevOps tools, and AI infrastructure systems.

Public Sandbox
Try attestd right now with demo key attestd_demo_key. No signup required.
Sandbox coverage includes nginx, log4j, OpenSSH, Apache HTTPD, PostgreSQL, Redis, WordPress, VMware ESXi, and Microsoft Exchange.