Kindal
Blog / Business Intelligence
Business Intelligence

Threat intelligence feeds: which ones are worth following

Threat intelligence feeds: which ones are worth following
Key takeaways
  • Threat intelligence feeds come in four kinds: vulnerability data, official advisories, indicators of compromise (IOCs) and research. Each answers a different question, so pick by job, not by volume.
  • A small team can cover most of what matters for free: CISA KEV, the CVE List or NVD, FIRST EPSS, CISA and vendor advisories, abuse.ch, OTX, SANS ISC and two or three vendor research blogs.
  • CISA KEV lists vulnerabilities with reliable evidence of exploitation in the wild. It is the shortest, highest-signal list a defender can follow, in CSV or JSON.
  • NIST now fully enriches only a subset of CVEs in the NVD, so filtering on an NVD severity score alone leaves most new CVEs unscored.
  • The filter that matters most is your own stack: a feed item is relevant when it names a product, vendor or technique that exists in your environment.

The short answer

The threat intelligence feeds worth following, by job:

  • Exploited vulnerabilities: CISA Known Exploited Vulnerabilities (KEV) catalog, because every entry has evidence of exploitation in the wild.
  • Vulnerability data: the CVE List and the NVD, because they are the reference records every tool maps to.
  • Exploitation likelihood: FIRST EPSS, because it ranks CVEs by the probability of exploitation.
  • Advisories: CISA advisories, CERT/CC Vulnerability Notes and the security advisories of your own vendors.
  • Indicators of compromise: abuse.ch (URLhaus, ThreatFox, MalwareBazaar) and LevelBlue OTX.
  • Context and research: SANS Internet Storm Center and two or three vendor research blogs.

All of these are free. The rest of this guide covers what each one carries, its format, and how to filter the set down to what touches your stack.

What is a threat intelligence feed?

A threat intelligence feed is a continuously updated stream of security data that a team subscribes to or pulls by machine. The data can be newly exploited vulnerabilities, vendor advisories, malicious URLs and IP addresses, malware hashes or written research on attacker behavior.

Feeds are not interchangeable. They fall into four kinds, and each answers a different question:

  1. Vulnerability feeds answer "which flaws exist, and which are being exploited?" Examples: CISA KEV, the CVE List, the NVD, EPSS.
  2. Advisory feeds answer "what should I patch or change, according to the vendor or a national CERT?" Examples: CISA advisories, Microsoft's Security Update Guide, CERT/CC.
  3. IOC feeds answer "which domains, IPs, URLs or files should my tools block or flag right now?" Examples: URLhaus, ThreatFox, OTX pulses.
  4. Research feeds answer "how are attackers operating, and what is changing?" Examples: SANS ISC diaries, Cisco Talos, Unit 42.

The format follows the kind. IOC feeds are built for machines: CSV, JSON, plain-text blocklists, STIX over TAXII. Advisories and research are built for people and arrive as web pages with RSS or Atom feeds.

Which threat intelligence feeds are worth following?

The feeds below were chosen for three properties: they are authoritative (published by the body that owns the data, or by a long-running community project), verifiable (each item points to its origin), and free to start. For each one: what it covers, format, cost and who it suits.

CISA Known Exploited Vulnerabilities (KEV) catalog

  • What it covers: vulnerabilities that CISA has added because they meet three criteria: an assigned CVE ID, reliable evidence of active exploitation in the wild, and clear remediation guidance. Each entry lists the vendor, product, a short description, the date added, a remediation due date and whether the flaw is known to be used in ransomware campaigns.
  • Format: CSV and JSON files, with a published JSON schema. Email updates are available through CISA's GovDelivery subscription.
  • Cost: free.
  • Who it suits: every team. A binding operational directive requires US federal civilian agencies to remediate KEV entries within set timeframes, and CISA recommends that every other organization treat the catalog as a patching priority too.

KEV is the highest-signal list in this article because it is short and every entry describes something attackers are already using. If a team follows only one vulnerability feed, the CISA KEV catalog is the one.

The CVE List and the National Vulnerability Database (NVD)

  • What they cover: the CVE List, run by the CVE Program, assigns the identifier and the base description of every publicly disclosed vulnerability. The NVD, run by NIST, adds analysis on top: CVSS severity scores, CWE weakness types and CPE product identifiers.
  • Format: the CVE List is published in CVE JSON 5 format in the CVEProject/cvelistV5 GitHub repository, refreshed about every seven minutes, with daily baselines and hourly delta files. The NVD offers the CVE API 2.0 and JSON 2.0 data feeds; the "recent" and "modified" feeds update about every two hours. The NVD retired its old RSS feeds when the 2.0 APIs launched.
  • Cost: free. The NVD API allows 5 requests in a rolling 30-second window without a key and 50 with a free API key.
  • Who they suit: teams that run vulnerability management tools or build their own matching against an asset inventory.

One change matters for anyone who filters on NVD scores. NIST has moved to risk-based enrichment: it now prioritizes CVEs in the KEV catalog, CVEs in software used by the federal government, and critical software as defined by Executive Order 14028. Other CVEs are marked lowest priority, not scheduled for immediate enrichment, according to the NIST announcement on NVD operations. NIST cites a 263% increase in CVE submissions over five years as the reason.

The practical consequence: a rule such as "alert me on NVD CVSS 9 and above" now stays silent for many new CVEs, because they carry no NVD score. The CNA that published the CVE may have included its own score in the CVE record, which is one reason to read the CVE List directly.

FIRST EPSS

  • What it covers: the Exploit Prediction Scoring System, maintained by FIRST, estimates the probability that a published CVE will be exploited in the wild in the next 30 days. Every CVE gets a score and a percentile.
  • Format: a public JSON API at api.first.org, daily CSV downloads, and data on GitHub.
  • Cost: free.
  • Who it suits: teams with more open vulnerabilities than patching capacity.

EPSS is not a list of news; it is a ranking you join to the other feeds. KEV tells you what is already exploited, EPSS tells you what is likely to be next, and together they turn a backlog of thousands of CVEs into a short queue. FIRST documents the model and the data on its EPSS page.

CISA cybersecurity advisories

  • What they cover: joint advisories on threat actors and campaigns, alerts, and industrial control system (ICS) advisories, including a separate stream for medical devices.
  • Format: RSS for all alerts and advisories, plus dedicated RSS feeds for ICS advisories and ICS medical advisories. Email through GovDelivery.
  • Cost: free.
  • Who they suit: any US organization, and especially operators of ICS and operational technology, where CISA's advisories are often the most complete public source.

Vendor security advisories (PSIRT feeds)

  • What they cover: official fixes and workarounds for the products you run. Microsoft's Security Update Guide, for example, publishes every CVE it addresses, with affected products and update details.
  • Format: varies by vendor. Microsoft offers an RSS feed of the Security Update Guide, plus an API and CSAF documents. Many large vendors publish advisories as RSS, CSAF or both.
  • Cost: free.
  • Who they suit: everyone, filtered to the vendors in your environment. The vendor is the primary source for its own products, and its advisory usually precedes the press coverage.

CERT/CC Vulnerability Notes

  • What it covers: vulnerability notes from the CERT Division of Carnegie Mellon's Software Engineering Institute, with summaries, technical details, remediation and lists of affected vendors. The database holds more than 3,500 notes across more than 2,300 vendors, according to the site.
  • Format: web database with an Atom feed of recently published notes.
  • Cost: free.
  • Who it suits: teams that need context on coordinated disclosures, especially issues that cut across many vendors, such as flaws in shared libraries or protocols.

abuse.ch: URLhaus, ThreatFox and MalwareBazaar

  • What it covers: community-sourced indicators. URLhaus collects URLs used for malware distribution. ThreatFox collects IOCs (IPs, domains, URLs, hashes) tied to named malware families. MalwareBazaar shares malware samples. Sibling projects include Feodo Tracker, SSL Blacklist and YARAify. abuse.ch runs these with Spamhaus as its primary licensee.
  • Format: for URLhaus, CSV and JSON dumps, plain-text URL lists, hostfile and DNS RPZ formats, Snort and Suricata rules, ClamAV signatures and a daily MISP feed. Most exports refresh every five minutes.
  • Cost: free under fair use. Downloads and API calls need a free Auth-Key from the abuse.ch authentication portal. abuse.ch states that commercial or for-profit use may require a paid subscription to its commercial API.
  • Who it suits: teams that can push indicators into a DNS filter, firewall, proxy, EDR or SIEM. These feeds are made for blocking and matching, not for reading.

LevelBlue Open Threat Exchange (OTX)

  • What it covers: a community platform, formerly AlienVault OTX, where researchers and vendors publish "pulses": collections of indicators about a specific threat, campaign or malware family.
  • Format: the DirectConnect API (with SDKs such as the OTXv2 Python package) returns the pulses you subscribe to. OTX also runs a free STIX/TAXII server, with your OTX API key as the username.
  • Cost: free with an account.
  • Who it suits: teams that want a broad community view and can curate subscriptions. Pulse quality varies by author, so subscribe to specific contributors you trust rather than everything.

SANS Internet Storm Center (ISC)

  • What it covers: daily diaries written by volunteer handlers about what they see in the wild, the short daily StormCast podcast, and data on scanning and port activity from sensors around the world.
  • Format: RSS for the diary (title-only and full-text versions) and the podcast, tab-delimited data feeds, a curated blocklist and an API.
  • Cost: free, under a Creative Commons Attribution-NonCommercial-ShareAlike license.
  • Who it suits: analysts who want a human read on emerging activity. SANS warns that its top-IP lists contain false positives and should not be used as blocklists; its curated block list is the only one it recommends for blocking.

Vendor research blogs

  • What they cover: long-form analysis of campaigns, malware and threat actors from teams with large telemetry. Cisco Talos, Palo Alto Networks Unit 42 and Microsoft Threat Intelligence all publish regularly, and Google's Threat Intelligence Group publishes on the Google Cloud blog.
  • Format: RSS for the Talos blog, the Unit 42 site and the Microsoft Security blog; research reports often append IOC lists or GitHub repositories.
  • Cost: free.
  • Who they suit: teams that need to understand attacker behavior in their sector. Pick two or three whose coverage overlaps your industry and technology. Following ten produces the same campaign written up ten times.

Are free threat intelligence feeds enough?

For most small and mid-sized teams, free feeds cover the essentials. KEV, EPSS and vendor advisories handle patch priority; abuse.ch and OTX handle commodity malware infrastructure; ISC and vendor research provide context.

What free feeds usually lack:

  • Sector and regional focus. Paid providers and sector ISACs can tell you what is targeting healthcare, finance or energy specifically.
  • Curation and scoring. Commercial feeds tend to deduplicate, age out stale indicators and attach confidence scores.
  • Support and service levels. Community projects run on fair use and can change terms, rate limits or availability.
  • Integration. Paid feeds often ship with connectors for specific SIEM, EDR or TIP products.

A useful test before paying: run the paid feed against your own logs for a few weeks and count how many hits it produced that your free feeds did not. If the number is small, the gap is in filtering, not in coverage.

How should a small security team combine feeds without drowning?

Combine feeds by deciding where each one goes, then filter every human-readable item against your own stack. Volume is not the problem; reading items that cannot apply to you is.

A workable setup for a team of one to five people:

  1. Write the inventory first. List vendors, products and versions, cloud services, identity providers and key open source components. This list is the filter for everything that follows.
  2. Send machine feeds to machines. URLhaus, ThreatFox and OTX indicators go into DNS filtering, the firewall, EDR or the SIEM, where they block or match automatically. Nobody should read them line by line.
  3. Build the patch queue from KEV plus EPSS. Every KEV entry that matches the inventory is urgent. Above that baseline, sort the remaining CVEs on your assets by EPSS rather than by severity score alone.
  4. Filter advisories by vendor. Subscribe to the PSIRT feeds of the vendors on your inventory, and to CISA advisories. Drop advisories for products you do not run before anyone reads them.
  5. Read research on a cadence. ISC and two or three vendor blogs, read weekly or twice a week, not as they arrive. Research rarely requires same-hour action; KEV additions for your stack do.
  6. Deduplicate by event. A single campaign will surface in a vendor blog, an OTX pulse, a CISA advisory and the trade press. Track it as one item with several sources, not as four alerts.
  7. Review quarterly. For each feed, ask what it changed in the last three months: a patch, a block, a detection, a decision. Drop the feeds that never produce an action.

The output of this setup is not a reading list. It is three short queues: what to patch, what to block, and what to understand.

How do you keep up with a fast-moving threat landscape?

You keep up by following fewer sources more closely and letting relevance, not recency, decide what reaches a person. The threat landscape moves faster than any team can read, so trying to read everything guarantees missing the item that applies to you.

Three habits make the difference:

  • Watch the primary source, not the coverage. The vendor advisory, the KEV addition and the researcher's write-up publish before the news stories about them. Following the press adds delay and duplicates.
  • Separate "urgent for us" from "interesting." A new KEV entry for a product you run is urgent. A well-written report on a threat actor targeting a different sector is interesting. Mixing the two in one inbox trains people to skim both.
  • Write down what changed. A short weekly note (new exploited flaws on our stack, advisories acted on, campaigns relevant to our sector) builds memory that a feed reader does not.

This is where AI monitoring helps. The structured feeds already have good tooling: SIEMs, TIPs and vulnerability scanners consume KEV, EPSS and IOC formats well. The gap is the human-readable layer, the advisories, diaries and research posts, where someone still has to read each item and decide whether it touches the stack. A model given your inventory can read those sources, discard what does not apply, merge the duplicates and write a short summary with links back to each original.

Kindal is one tool that works this way for the reading layer: you choose sources such as RSS feeds, vendor blogs and advisory pages, and it writes a brief only when something changes, with every line linked to its source. It is not a SIEM or a threat intelligence platform, and it does not ingest IOCs or block anything; it covers the advisories and research a person would otherwise read by hand.

What mistakes do teams make with threat feeds?

The common mistakes come from treating feeds as a volume problem rather than a relevance problem.

  • Subscribing before inventorying. Without an asset list, every advisory looks potentially relevant, and the team reads all of them or none.
  • Reading IOC feeds. Indicators belong in tools. A person scrolling through malicious URLs adds no value and burns attention.
  • Prioritizing by severity score alone. A critical CVSS score on an unexploited flaw in software you barely use can outrank an exploited medium-severity flaw on an internet-facing system. KEV and EPSS correct that ordering.
  • Assuming the NVD has scored everything. With NIST enriching only a subset of CVEs, many new records carry no NVD severity. Rules built on NVD scores need a fallback, such as the CNA score in the CVE record or EPSS.
  • Using research data as a blocklist. Scanning data and community lists can include false positives. SANS says so explicitly about its top-IP lists. Block only on lists built for blocking.
  • Never pruning. Feeds accumulate. Without a quarterly review, the set grows until nobody trusts any of it.

Choosing your feeds

The feeds worth following are the ones that change what your team does. For most teams that means CISA KEV and EPSS for patch priority, the advisories of your own vendors, abuse.ch or OTX wired into your blocking tools, and a few research sources read on a schedule.

Start with the inventory, route each feed to where it can act, and review the set every quarter. The goal is not to see every new threat. It is to know, each week, which ones touch your environment and what you did about them.

Frequently asked questions

What is a threat intelligence feed?

A threat intelligence feed is a continuously updated stream of security data that a team can subscribe to or pull by machine, such as newly exploited vulnerabilities, vendor advisories, malicious URLs, IP addresses, file hashes or research reports. Feeds differ by what they carry and how they deliver it. Some publish structured data in CSV, JSON or STIX over TAXII, built for firewalls, SIEMs and threat intelligence platforms. Others publish human-readable advisories and research through RSS or Atom. A feed only becomes intelligence when someone, or some system, decides which items apply to their own environment and what to do about them.

Are there free threat intelligence feeds?

Yes, and several of the most authoritative ones are free. CISA's Known Exploited Vulnerabilities catalog is published as free CSV and JSON files. The NVD offers a free API and JSON data feeds, and the CVE List is published on GitHub. FIRST publishes EPSS exploitation scores through a free public API. abuse.ch projects such as URLhaus, ThreatFox and MalwareBazaar are free under fair use, with a free Auth-Key, though commercial use may require a paid subscription. LevelBlue's Open Threat Exchange (OTX) is free with an account. SANS Internet Storm Center feeds are free under a non-commercial Creative Commons license.

How do you use threat intelligence feeds?

Start from what you run, not from the feeds. List the vendors, products, cloud services and open source components in your environment, then subscribe only to the feeds that can say something about them. Route machine-readable IOC feeds, such as URLhaus or ThreatFox, into the tools that can block or match them: firewall, DNS filter, EDR or SIEM. Route vulnerability feeds, such as CISA KEV and EPSS, into patch prioritization. Read advisories and research on a fixed cadence, filtered by your stack. Review each feed every quarter and drop the ones that never produce an action.

How do you choose a threat intelligence feed provider?

Judge a provider on five things. Relevance: does it cover the industries, regions and technologies you actually run? Provenance: can you see where an indicator came from and when it was last seen? Freshness: how quickly are items added and expired? Format: does it deliver in a format your tools can ingest, such as STIX over TAXII, JSON or CSV? False positive handling: does it remove or age out stale indicators? Test a provider against your own logs for a few weeks before paying. If a paid feed mostly repeats free sources you already follow, it adds cost without adding coverage.

Is MITRE a threat intelligence feed?

Not in the usual sense. MITRE is associated with two resources that security teams use every day, but neither is a stream of live threat data. The CVE List, which MITRE has operated for the CVE Program, is a catalog of vulnerability identifiers and descriptions; it is published continuously, so it behaves like a vulnerability feed, but it does not say whether a flaw is being exploited. MITRE ATT&CK is a knowledge base of adversary tactics and techniques. It is a shared vocabulary for mapping threats and detections, not a source of new indicators. Teams use ATT&CK to tag and compare the intelligence that their feeds deliver.

What is the difference between a threat feed and a threat intelligence platform?

A threat feed is a source of data; a threat intelligence platform (TIP) is the software that collects many feeds, normalizes them, removes duplicates, scores indicators and pushes them to security tools. A feed such as ThreatFox delivers indicators. A platform such as MISP or a commercial TIP stores those indicators next to others, tracks sightings and lets analysts add context. Small teams often skip the platform at first and connect a few feeds directly to their firewall, DNS filter or SIEM. A platform becomes worth its overhead when the number of feeds, the volume of indicators or the need to share intelligence with partners grows past what manual work can handle.

SW

Soren Whitaker

Business Intelligence

Competitive and market intelligence: what a company signals, where it signals it, and how to notice a change in direction early.

Related articles