CVE Feed: Build Alerts That Lead to Action

A CVE feed is not an alerting system. It is source change data. Until your pipeline handles revisions, matches exact product state, explains urgency, assigns an owner, and verifies closure, faster delivery only creates noise sooner.

The common design is simple: poll NVD, filter for critical scores, send email. It also fails in predictable ways. Product names do not match inventory. Old records change. Rejected IDs remain open. A vendor publishes a fixed package that looks older than upstream. One mass schema update floods the modified queue and wakes the team.

Ranking pages tend to list feed providers or show a keyword alert. Operators need a data contract and recovery model. This guide builds one with official sources, a verified NVD query, a fixed checkpoint, and an alert gate tied to assets your organization actually owns.

What is a CVE feed?

A CVE feed is a machine readable stream or recurring download of vulnerability records and their changes. The unit is not just a new CVE ID. A useful feed includes publications, modifications, rejections, source metadata, and enough structured content to reconcile the local copy.

The official CVE List carries CNA supplied records. NVD ingests those records and adds federal search, configuration, scoring, status, and other assessment data. CISA KEV supplies evidence that a vulnerability has been exploited. Vendor advisories carry the strongest product and repair detail. These are related sources with different jobs, not interchangeable mirrors.

Start with the CVEs and vulnerability intelligence pillar guide for the whole chain. The National Vulnerability Database guide explains where NVD enrichment begins and where local evidence must take over.

Which CVE feed sources should you use?

Use the official CVE List when you need the assigned record as published by its CNA. The CVE List V5 repository says it refreshes from CVE Services about every seven minutes. It offers a daily baseline at midnight UTC and hourly delta archives. A local Git mirror is also supported.

Choose NVD when you need targeted API retrieval, CPE search, federal enrichment, change history, or bulk 2.0 feed files. Keep provider identity beside every metric. A CNA score and an NVD score can differ without either one being part of the permanent CVE identity.

Add CISA KEV for confirmed exploitation and use vendor sources for fixed builds, backports, workarounds, known issues, and product status. The security advisory guide shows how Microsoft, Red Hat, and Apple publish those facts. Your source table should name authority, content, cadence, schema, license, retry policy, and owner.

Why does a raw CVE feed overwhelm teams?

Volume turns a loose inbox into a broken process. The CVE Program report published May 12, 2026 recorded 15,176 published CVE Records in the first quarter. That is an average of about 169 records per day.

If an analyst spends four minutes reading every new record, the daily queue consumes more than 11 hours. Nothing has been matched to inventory yet. No vendor fix has been checked. No owner has changed a system. A feed that pages on score alone converts public publishing capacity into private labor cost.

Filter late enough to preserve source truth and early enough to protect human attention. Ingest all relevant changes into a durable store. Alert only after the record joins an asset or product you own and crosses an action rule. Batch weak matches for review instead of pretending a keyword is proof.

How should an incremental CVE feed work?

1. Choose a closed start and end time for the polling window.
2. Fetch every page for that fixed window before advancing the checkpoint.
3. Store the raw response, retrieval time, source schema, and request parameters.
4. Upsert by CVE ID while preserving publication, modification, provider, and status history.
5. Replay a small overlap and deduplicate by ID plus source modification time.
6. Advance the checkpoint only after durable storage and validation succeed.

Fixed windows make recovery explainable. If page seven fails, rerun the same interval. If a schema check fails, keep the checkpoint still and open an ingestion exception. Never turn an empty or malformed response into “no vulnerabilities today.”

Reconcile on a schedule even when incremental polling looks healthy. Compare record counts, current states, and a sample of content hashes against a fresh baseline. The incremental path is optimized for speed. The baseline path proves completeness. Give each one a separate checkpoint and alert, so a successful fast poll cannot hide a broken recovery job. Test restoration into an empty database before an incident forces the exercise.

The official NVD CVE API documentation defines the lastModStartDate, lastModEndDate, resultsPerPage, andstartIndex parameters. It also requires API keys in the apiKey request header.

curl --fail --silent --show-error --get \
  -H "apiKey: ${NVD_API_KEY}" \
  'https://services.nvd.nist.gov/rest/json/cves/2.0/' \
  --data-urlencode 'lastModStartDate=2026-08-28T00:00:00.000' \
  --data-urlencode 'lastModEndDate=2026-08-29T00:00:00.000' \
  --data-urlencode 'resultsPerPage=2000' \
  --data-urlencode 'startIndex=0' \
  | jq '.vulnerabilities[] | .cve | {id, published, lastModified, status: .vulnStatus}'

This request syntax and the date parameters were verified against the live 2.0 API on August 29, 2026. A one day test window returned 2,587 modified results, so production code must page rather than assume one response. Replace the dates with a fixed scheduler window, keep the API key outside source control, respect response status and rate limits, and retry with delay.

How do you handle revised and rejected CVEs?

Model a CVE as a versioned source object. Keep its current state for search and its prior states for audit. A modification can add affected versions, remove a false product match, change a score, add a fix, mark a dispute, or reject a duplicate. Each change can alter an open ticket.

Route field changes by consequence. A new fixed version updates repair instructions. A new KEV date shortens the clock. A changed affected range reruns product matching. Rejection closes or merges the public case, but it should not erase prior ticket history. A reference change may require no alert unless the source is used for a repair command.

Store provider and source container. Modern CVE Records can have CNA, CVE Program, and Authorized Data Publisher containers. Flattening all fields without provenance makes later corrections hard to explain. TheCVE record guide covers the current container model.

What CVE feed changes landed in the last 12 months?

NVD changed both payload content and history delivery in 2026. The NIST NVD update log says the June 17 deployment added CISA supplied SSVC and CVE affected data to feeds and API responses. The refresh touched about 95 percent of existing vulnerabilities, causing larger modified payloads and widespread new modification times.

On August 26, 2026, NVD changed /cvehistory entries for affected data. The history feed now points to the relevant GitHub record instead of embedding the full affected object in each audit entry. The current/cves/ endpoint still returns the latest full affected data.

These are not cosmetic changes. A consumer that treats every modified time as a new security event will flood the queue after a broad refresh. A parser that expects embedded affected history will lose detail after August 26. Track schema and delivery changes as software releases, test them, and separate source maintenance from risk escalation.

How should a CVE feed match local inventory?

Normalize products without discarding source text. Join vendor, product, package ecosystem, Package URL, CPE, version type, architecture, edition, and platform to observed inventory. Then check installed fix state, component presence, feature configuration, process use, network exposure, privilege path, and controls.

Version comparison needs product rules. Semantic versions, RPM and Debian package versions, Windows builds, firmware, Git commits, and vendor backports do not share one ordering algorithm. “String is inside affected range” is not a universal matcher. Preserve unknown when evidence is incomplete.

The output should say why an asset matched. Example: “CVE record names Example Server before 4.2.1. Endpoint A reports package 4.2.0, the vulnerable module is loaded, port 8443 is reachable from the partner network, and no blocking control was observed.” That sentence can support an action. A red score cannot.

What should trigger a CVE alert?

Alert when a changed source fact creates or changes an owned decision. Good triggers include confirmed product matches on exposed assets, known exploitation, a new functional exploit with matching prerequisites, a fix for an open exception, a materially wider affected range, or a mitigation that invalidates current guidance.

Every alert should name the source revision, affected asset, matching evidence, reason for urgency, owner, required action, due time, and verification test. Suppress duplicates only when those decision fields are unchanged. Batch records that match only a vendor keyword or uncertain product label.

Deep endpoint context with AI driven analysis can help interpret affected ranges, system state, and exact repair commands. Artemes uses that model to turn source updates into reviewable actions. The raw record and local evidence should remain visible so an operator can challenge the result.

Which CVE feed metrics matter?

• Source delay from publication or modification to durable ingestion.
• Checkpoint age, failed windows, replay count, and schema exceptions.
• Exact matches, uncertain matches, false matches, and assets with unknown versions.
• Alerts that created action, duplicates suppressed, and unowned urgent cases.
• Time from source change to verified containment or repair.

Do not celebrate records processed. That is an input counter. Measure decisions improved, noise prevented, and repair time reduced. A pipeline that ingests a million objects and misses one exposed gateway is not healthy.

Frequently asked questions about CVE feeds

Is there one official CVE RSS feed?

The CVE Program provides the official CVE List through its V5 repository and release archives. For automation, use supported machine data rather than depending on a simple headline stream.

Should a team use the NVD API or bulk feeds?

Use the API for bounded queries and targeted retrieval. Use bulk feeds or the CVE List repository for local mirrors and large reconciliation jobs. Design recovery before choosing cadence.

How often should a CVE feed run?

Match cadence to action. Hourly is reasonable for exposed critical products if the pipeline can recover and the team can act. A daily batch may fit low exposure inventory. Faster polling cannot fix slow ownership.

Does a critical CVSS score deserve an immediate page?

Not by itself. Page when severity joins a credible asset match and urgent conditions such as exposure, known exploitation, important function, or a narrow repair window.

The executive takeaway

Take one day of feed changes and replay it through your pipeline. Prove that a new record, a revised affected range, a rejected ID, and a known exploited item each reach the right state without duplicate pages. Then pick ten alerts and require an exact asset, source revision, owner, action, and verification test. If the feed cannot produce those facts, slow it down and fix the contract.