Safeguard
Research•

What is threat intelligence? A plain explanation for engineers and buyers

Threat intelligence is analysed information about attackers and their methods, used to make decisions. What it is, its types and how to judge a feed.

Safeguard Security Team
5 min read

Threat intelligence is information about attackers, their methods and their targets that has been analysed and put in context so you can make a decision with it. A list of bad addresses is data. A report saying who targets your sector, how, and what to check is intelligence.

What is the official definition?

NIST describes cyber threat intelligence as threat information that has been aggregated, transformed, analyzed, interpreted or enriched to provide the necessary context for decision making processes. The words that matter are "context" and "decision". If nobody can act on it, it is not yet intelligence.

NIST SP 800-150 defines cyber threat information more broadly as any information that can help an organization identify, assess, monitor and respond to cyber threats. It includes indicators of compromise, the tactics, techniques and procedures used by threat actors, suggested actions to detect, contain or prevent attacks, and findings from analyses of incidents.

What are the common types?

People often split it by who reads it. These labels are common usage, not a formal standard.

Strategic. For leaders: which kinds of attackers target your sector and what they want. Informs budgets and priorities.

Operational. For the security team: what campaigns are active and how they work. Informs what to look for this month.

Tactical. For defenders and engineers: the methods attackers use, such as techniques from MITRE ATT&CK, a knowledge base of adversary tactics and techniques based on real world observations. Informs detections.

Technical indicators. Specific artefacts such as file hashes, addresses and domains. Useful, but short lived, since attackers change them.

Where does it come from?

Typical sources: government bodies, sector sharing groups, vendor advisories, open reports, and your own incident data. CISA's Known Exploited Vulnerabilities catalog is a public example of intelligence you can use at once: it lists flaws with evidence of exploitation. FIRST's EPSS adds a daily estimate of the probability that a CVE will be exploited in the next 30 days.

NIST SP 800-150 describes how to take part in information sharing relationships, and notes that organisations that share can improve their own security and others'.

What is it used for?

Four common uses.

  • Prioritising patches. Known exploited flaws go first.
  • Writing detections. Techniques seen in reports become rules.
  • Informing hunts. Teams search their data for patterns from reports.
  • Explaining risk. Leaders see why a topic matters now.

How do you judge a feed or report?

Ask five questions.

  1. Is it relevant to us? Do we run the product, use the service or sit in the sector?
  2. Where did it come from, and how sure are they? Look for the source and the confidence stated.
  3. Is it fresh? Indicators go stale quickly.
  4. Can we act on it? A report with no suggested action costs time.
  5. Can we check it? Prefer claims with references to advisories or technical detail.

Be sceptical of volume. A feed of a million indicators is not better than a short, relevant one. The cost is analyst time, and false matches burn trust.

What are common mistakes?

  • Treating all feeds as equal, and loading them all into blocking systems without testing.
  • Never recording relevance, so the same report is read again.
  • Forgetting your own data. Your incidents and logs are intelligence about your attackers.
  • Buying a feed before you know what decision it will change.

What about open source software?

Intelligence on exploited flaws in packages should flow into your dependency process. A report about a library matters only if you can answer which of your applications use it, and whether the vulnerable code is reachable. That needs an inventory.

What to do

  1. Decide the decisions you want intelligence to inform: patch order, detections, hunts.
  2. Start with free, narrow sources: advisories for products you run, and the exploited flaws catalog.
  3. Record a relevance check for every report: do we run it, is it reachable, is the version affected?
  4. Test any indicator in alert mode before blocking.
  5. Keep a simple log of what you read and what changed because of it.
  6. Share with a sector group when you can.

Safeguard focuses on the application and software supply chain side and does not replace a threat intelligence service.

Quick check

Is a list of malicious IP addresses threat intelligence?

By NIST's definition, only if it has context for a decision. A bare list is threat data. It becomes intelligence when someone has analysed where it came from and what to do.

What is the best free source to start with?

For patch priority, CISA's catalog of known exploited vulnerabilities is a strong start, together with advisories for the products you run.

Sources

Last reviewed: 18 October 2026.

Never miss an update

Weekly insights on software supply chain security, delivered to your inbox.

Self-healing security runs on Safeguard.

Your first fix PR is minutes away.

No sales call required, even your agent can complete the purchase over MCP.