CVE Triage

Lookups are cached for 24 hours (a repeat costs 1 credit). Batch calls take 1 to 100 ids, are never cached, and return results keyed by id, with null for an id that is unknown or suppressed. CVE ids are case insensitive and must match CVE-YYYY-NNNN; anything else returns 422.

CVEs added to the KEV catalogue in the last days (default 7), enriched with EPSS and NVD data, up to limit results (default 50). Useful as a daily feed into a ticket queue.

curl "https://api.stackbyte.app/v1/cve/recently-exploited?days=7&limit=50" \
  -H "X-API-Key: $STACKBYTE_KEY"

Keys follow the Elastic Common Schema vulnerability.* fields where one exists, and everything Stackbyte adds lives under stackbyte.*. The record is flat: each key is a single string containing dots, not a nested object, so it maps straight to a column in Splunk, Sentinel, a data warehouse or a spreadsheet. A field with no value is null, never guessed.

The first rule that matches sets the priority.

The rules rank by evidence of exploitation first, then likelihood, then severity. They are a starting order, not a replacement for knowing your own exposure: a flaw in software you do not run can wait whatever its priority.

Score the CVEs your scanner reports once a night, write the result to a lookup file, then join it in any search. open_cves.json holds {"ids": [...]} with up to 100 ids per call; loop for more.

# Score the CVEs your scanner found and write a Splunk lookup file.
# Run nightly from cron on a search head, after the scanner import.
curl -s -X POST https://api.stackbyte.app/v1/cve/batch \
  -H "X-API-Key: $STACKBYTE_KEY" -H "Content-Type: application/json" \
  -d @open_cves.json \
| jq -r '["cve","priority","epss","kev","ransomware"],
    (.data | to_entries[] | select(.value != null) | [
      .key,
      .value["stackbyte.triage.priority"],
      .value["stackbyte.epss.score"],
      .value["stackbyte.kev.listed"],
      .value["stackbyte.kev.known_ransomware_campaign_use"]
    ]) | @csv' \
> "$SPLUNK_HOME/etc/apps/search/lookups/stackbyte_cve.csv"

KQL externaldata cannot send an API key header, so pull the scores in with a Logic App and query them from a custom table:

1. Recurrence trigger, once a day after your vulnerability data refreshes.
2. HTTP action: POST https://api.stackbyte.app/v1/cve/batch with header X-API-Key (from Key Vault) and body {"ids": [...]}.
3. Send the records to a custom table, for example StackbyteCve_CL, through the Logs Ingestion API with a data collection rule that maps stackbyte.triage.priority to TriagePriority, stackbyte.epss.score to EpssScore and stackbyte.kev.listed to KevListed.

// StackbyteCve_CL: filled daily by a Logic App (see steps above),
// columns CveId, TriagePriority, EpssScore, KevListed.
let triage = StackbyteCve_CL
    | where TimeGenerated > ago(2d)
    | summarize arg_max(TimeGenerated, *) by CveId;
DeviceTvmSoftwareVulnerabilities
| join kind=inner triage on CveId
| where TriagePriority in ("P1", "P2")
| summarize Devices = dcount(DeviceId) by CveId, TriagePriority, EpssScore, KevListed
| order by TriagePriority asc, EpssScore desc

DeviceTvmSoftwareVulnerabilities comes from Microsoft Defender Vulnerability Management; any table with a CVE id column works the same way.

Every response carries these attribution sentences, and so does this page:

• Includes data from the CISA Known Exploited Vulnerabilities Catalog (CC0). Not endorsed by CISA.
• EPSS scores by FIRST.org (https://www.first.org/epss/), used with attribution as requested by FIRST.
• This product uses the NVD API but is not endorsed or certified by the NVD. CVE is a registered trademark of The MITRE Corporation.