Vulnerability Intelligence: Beyond a CVE Feed

Vulnerability intelligence is not a larger CVE feed. It is the evidence that lets a named owner make a sound repair, mitigation, acceptance, or no action decision.

Most teams already have enough vulnerability data. They have scanner findings, vendor notices, CVSS scores, exploit reports, tickets, and asset inventories. The failure happens between those systems. A source changes, a product match is weak, nobody can explain the priority, and the ticket reaches an infrastructure team with no safe action or closure test.

Current ranking guides tend to define sources and promise better prioritization. That is incomplete. Operators need source provenance, update rules, local state, a decision contract, and proof that the action worked. This guide builds that operating layer and shows the math behind it. Our CVE enrichment guide defines the claim level data contract beneath it.

What is vulnerability intelligence?

Vulnerability intelligence is analyzed information about a software or hardware weakness that helps an organization decide whether, when, and how to act. It starts with public facts such as a CVE Record, vendor affected versions, severity, known exploitation, exploit probability, and available fixes. Then it joins those facts to actual assets, network routes, runtime use, controls, business function, repair risk, and ownership.

The word intelligence matters because collection alone does not answer a decision. A CVE record identifies a case. A CVSS score describes technical severity under stated assumptions. CISA KEV records evidence of exploitation. EPSS estimates a 30 day exploitation probability. None of them proves that a vulnerable package exists on one server or that its affected code can run.

For wider context, the CVEs and vulnerability intelligence pillar guide explains how those public systems connect. A working vulnerability intelligence program adds the local and operational facts that public publishers cannot know.

How is vulnerability intelligence different from vulnerability data?

Data is a statement with a source and time. Intelligence is a supported conclusion for a specific consumer. "CVE-2021-44228 is in CISA KEV" is data. "The customer portal loads an affected Log4j Core version, accepts internet input, and must move to the supported release tonight" is intelligence. The second statement can create work without forcing the owner to repeat the whole investigation.

Three tests separate the two. Can the reader see where each fact came from? Can the conclusion change when source or asset state changes? Does the output name an owner, action, and verification method? If any answer is no, the system is probably decorating a feed.

Which signals belong in a vulnerability intelligence record?

Start with authoritative identity and product scope. Preserve the CVE ID, publisher, record state, vendor advisory, affected version expression, fixed version, publication time, revision time, weakness, and severity vector. Keep the raw source beside normalized fields. Parsers fail, vendors correct ranges, and records change.

Add threat evidence next. The CISA Known Exploited Vulnerabilities JSON catalog contained 1,685 records in version 2026.08.27 when checked on August 29, 2026. Of those, 352 were marked as known ransomware campaign use. Those values are a dated snapshot, not permanent constants. Store catalog version, retrieval time, date added, required action, due date, and ransomware field.

Probability supplies a different signal. FIRST put EPSS v5 into service on June 15, 2026. Its July 2026 EPSS v5 announcement describes refreshed training, updated exploit code detection, improved calibration, VulnCheck KEV data, and GitHub popularity metrics. Downstream consumers did not need an API change, but some scores changed. A sound record therefore keeps score date and model version, not only the latest decimal.

Local evidence finishes the record: exact package or build, installation path, process state, feature use, reachable route, privilege, data handled, compensating control, service owner, maintenance window, rollback path, and the command or query that will prove closure.

Why does this operating layer matter now?

Verizon published its 2026 Data Breach Investigations Report on May 19. The 2026 DBIR findings say vulnerability exploitation accounted for 31 percent of breach initial access. In the manufacturing snapshot, organizations fully repaired 26 percent of critical vulnerabilities, defined there as KEV entries, and median full resolution reached 43 days.

That is an execution problem. More feeds will not repair it. The useful question is whether the system can move an exploited vulnerability on an exposed service to the right owner before a broad severity queue consumes the available change windows.

What should the decision contract contain?

Unknown is a valid status. It should create an investigation with an owner and expiry, not silently become low risk. Also separate observation from inference. A scanner saw a version string. A vendor rule says that version is affected. An analyst concludes the service needs repair. Those are three different records.

How do you test public vulnerability intelligence feeds?

Pull the official source, keep its release metadata, and select a known case. The following commands were run successfully on August 29, 2026.

curl -fsSL \
  'https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json' \
  | jq --arg cve 'CVE-2021-44228' \
  '.vulnerabilities[] | select(.cveID == $cve)'

curl -fsSL \
  'https://api.first.org/data/v1/epss?cve=CVE-2021-44228' \
  | jq '.data[] | {cve, epss, percentile, date}'

The official FIRST EPSS API reference allows multiple comma separated CVE IDs and historic date queries. Validate HTTP status, response schema, requested IDs, score date, and missing records. A successful request with an empty result is not evidence of low probability.

What does prioritization math look like?

Consider a hypothetical queue of 10,000 scanner findings and capacity to repair 40 each week. A flat queue represents 250 weeks of work. Suppose product matching removes 6,800 false or irrelevant cases, runtime and reachability remove 2,500 more, and exploit evidence plus asset impact place 180 cases in the first action band. That band is 4.5 weeks of work at the same capacity.

The arithmetic does not prove the 180 are correct. It exposes the assumptions. A CISO can ask why 180 survived, an owner can challenge one match, and the team can measure how many decisions were later reversed. A secret vendor score cannot support that conversation.

How should vulnerability intelligence handle conflicting sources?

Conflicts are normal. A CVE Record may describe a broad upstream version range while a Linux vendor says its supported package is not affected because the vulnerable code was never included. NVD may publish one score and the vendor another. A proof repository may call an example functional while an incident source has seen no exploitation. Flattening those statements into one value throws away the reason for each claim.

Set precedence by field, not by publisher reputation alone. Use the responsible vendor for supported product and fixed build statements. Use the CVE Program for record identity and state. Use CISA KEV for its documented exploitation determination. Use FIRST for EPSS probability on its stated date. Preserve every source value when a difference could affect action.

Then record the local conclusion separately. An operator might accept the vendor's unaffected package status after confirming the exact distribution build, while retaining the broader upstream range for audit. That is a reasoned decision. Replacing the upstream value with "false" is data loss.

How do you measure vulnerability intelligence quality?

Sample decisions, not feed rows. Each week, pull 20 closed affected cases, 20 closed not affected cases, and the oldest unknown cases. Recheck source versions, asset observations, owner assignments, repair commands, and closure evidence. Count unsupported conclusions and stale proof. A low error rate on CVE ingestion means little if product matching or ownership fails later.

Measure time at the handoffs. Publication to normalized record shows collection speed. Record to supported local status shows matching performance. Supported status to owner shows routing. Owner to verified state shows repair execution. One average hides the queue that needs work, so keep those intervals separate and report the oldest exceptions beside the median.

How should a vulnerability intelligence workflow run?

1. Ingest official records and revisions with source and retrieval times.
2. Normalize identity, product scope, severity, exploitation, probability, and remediation facts.
3. Join those facts to observed asset, dependency, runtime, network, control, and owner state.
4. Create a reasoned action band and show every rule that contributed to it.
5. Generate repair or mitigation instructions with test and rollback terms.
6. Requery after change, store fresh proof, and reopen the case when source or asset state changes.

Deep endpoint context with AI driven analysis can reduce manual joins and draft exact remediation commands. Artemes uses that model, but the output still has to show its sources, observed state, reasoning, and closure evidence. An unexplained answer is a new queue, not intelligence.

Which failure modes create expensive intelligence?

Teams often overwrite old source data with the newest value. That destroys the record of why a decision was made. Store revisions and effective times. Another common failure is confusing no match with not affected. Parser errors, weak product names, and stale inventories all create unknowns that deserve visible treatment.

A third failure is letting a score choose the action. KEV can accelerate a case. EPSS can order review. CVSS can describe impact. Business criticality can raise consequence. The owner still needs a supported affected claim, a safe change, and a way to prove the result.

Frequently asked questions about vulnerability intelligence

Is vulnerability intelligence the same as threat intelligence?

No. Threat intelligence covers adversaries, campaigns, infrastructure, behavior, and indicators. Vulnerability intelligence focuses on weaknesses, affected products, exploitation, local exposure, and action. The two meet when campaign evidence changes a vulnerability decision.

Does vulnerability intelligence replace scanning?

Scanning supplies observations about systems. Intelligence checks those observations against authoritative product and threat facts, then adds context and action. Weak observations produce weak conclusions, so the two functions depend on each other.

How often should feeds refresh?

Check critical public and vendor sources at least daily, and faster during an active event. Process updates, rejections, and deletions. Refresh local state often enough to support the decision deadline.

What is the best vulnerability intelligence metric?

Measure decision quality and execution: time to supported affected status, time to owner, repair throughput, exception age, reversal rate, and percent of closures backed by fresh evidence. Feed volume is not a success metric.

The executive takeaway

Choose one exploited vulnerability and trace it from source publication to closed work. Demand the exact product rule, observed asset state, owner, action, rollback plan, and fresh verification. Any missing field is the next system problem to fix. Do that before buying another feed.