Threat intelligence helps a vulnerability and software supply chain program by answering one question: which of these flaws are attackers actually using? It does not replace scanning or patching. It orders the queue, flags urgent cases, and supplies context for decisions about packages and builds.
Why does the queue need help?
Scanners report severity. The CVSS user guide states that Base scores measure the severity of a vulnerability and should not be used alone to assess risk, and that threat and environment metrics should supplement them. A severe flaw nobody exploits can wait. A moderate flaw under active attack may not. Threat intelligence is the missing threat input.
What should you pull in?
Start with three public sources that cost nothing.
CISA's Known Exploited Vulnerabilities catalog lists vulnerabilities with observed exploitation, and CISA says organizations should use it as an input to prioritization.
EPSS, run through FIRST, estimates the probability that a CVE will be exploited in the next 30 days. FIRST is explicit that it is not a complete risk score, because it ignores your environment and impact.
CISA's SSVC decision model combines exploitation status, technical impact, whether exploitation is automatable, mission prevalence and public well being impact into four outcomes: Track, Track with extra monitoring, Attend and Act.
A paid feed adds value if it covers things these do not: early reports before a CVE exists, details on a campaign, or advisories on malicious packages.
How does it connect to supply chain work?
Software supply chain risk has two shapes. One is a known vulnerability in a component you ship. The other is a component that is itself malicious or tampered with. Intelligence helps both.
For vulnerable components, exploitation data feeds prioritization. Combine it with whether your code actually reaches the vulnerable function. A flaw that is exploited in the wild but unreachable in your application has lower urgency than one that is reachable and under attack.
For malicious or compromised packages, you need advisories about specific package names and versions, and your own inventory to check against. Without a software bill of materials, you cannot answer "are we affected?" in an hour. NIST's Secure Software Development Framework (SP 800-218) gives a common vocabulary for producer practices, including responding to vulnerabilities, and purchasers can use it in conversation with suppliers.
A worked ordering (constructed)
Imagine four open findings. This example is constructed.
A: severe, in KEV, reachable. Fix now. B: severe, not in KEV, low EPSS, unreachable. Schedule. C: moderate, in KEV, reachable in a build tool only. Fix soon, and check whether the build tool touches secrets. D: moderate, not exploited, reachable. Normal cycle.
The ordering came from three questions: is it exploited, is it reachable, what does it touch. Severity alone would have put B first.
How should the workflow run?
Ingest daily. KEV and EPSS update on their own schedules, so a finding's priority can change without any change on your side. Alert on state changes: a CVE entering KEV, an EPSS jump, a new advisory for a package you use.
Set response times by outcome, not by feeling. SSVC style categories, or your own two or three tiers, give engineers a clear expectation. NIST SP 800-40 Rev. 4 frames patching as preventive maintenance and recommends an enterprise strategy rather than ad hoc work.
Keep a feedback loop. When intelligence changes a priority, note it. After a quarter you will know which sources earn their cost.
What to ignore
Unsourced claims of imminent attacks. Reports that name an actor but give no behavior you can detect. Indicator lists with no dates. Anything you cannot connect to software or assets you run.
Where Safeguard fits
Reachability analysis shows whether a vulnerable function is called in your code, which pairs with exploitation data for ordering. Policies, gates and guardrails can enforce the outcome at build, CI and release, and fix pull requests are available but off by default. Safeguard does not sell a threat intelligence feed.
What to do
- Pull KEV and EPSS into your vulnerability queue.
- Add reachability so exploited but unreachable items drop in urgency.
- Keep a software inventory that can answer "are we affected?" quickly.
- Subscribe to advisories for the ecosystems you use.
- Define response times per outcome tier.
- Review monthly which sources changed decisions.
Quick check
Does EPSS replace CVSS?
No. CVSS describes severity and EPSS estimates exploitation probability. Neither measures impact on your environment, so use both with context.
What is KEV?
CISA's catalog of vulnerabilities with observed exploitation, intended as an input to prioritization.
Sources
- CVSS v4.0 User Guide
- CISA Known Exploited Vulnerabilities
- FIRST EPSS FAQ
- CISA SSVC
- NIST SP 800-218
- NIST SP 800-40 Rev. 4
Last reviewed: 18 October 2026.
