Why your threat intelligence is mostly noise

Anyone can aggregate threat intelligence feeds. NVD, GitHub Security Advisories, CISA KEV, Abuse.ch, AlienVault OTX, a handful of RSS feeds: in an afternoon you have a system that swallows tens of thousands of threats. The problem is that at that point you have built a machine for generating noise, not intelligence. The metric that matters is not how many threats your system tracks - it is how many a human actually decides to act on. It is the most counterintuitive truth of this craft: the value is in suppression, not aggregation. When I built Valta's relevance engine, that was the question driving me: how do I get from thousands of threats down to the handful that matter, for this organization, today?

What threat intelligence (really) is

Before cutting the noise, you need to know what you are cutting. CTI has three levels: strategic (who targets your sector, the trends), operational (the campaigns, the attackers' techniques) and tactical (IOCs, indicators of compromise: hashes, IPs, domains). Most "threat intelligence products" sell the tactical level - IOC feeds - which is also the least durable: as David Bianco's "Pyramid of Pain" reminds us, an attacker changes a hash or an IP in a minute. And around all of it sits a discipline, the intelligence cycle (direction, collection, processing, analysis, dissemination, feedback): intelligence is not a feed, it is a process that starts from a question and ends in a decision.

Severity is not priority: the limit of CVSS

Here is the most widespread conceptual mistake. CVSS, the score used to measure vulnerabilities, tells you how bad a flaw is if exploited - in the abstract, in a vacuum. It says nothing about how likely it is to be exploited, or whether it concerns you. And that gap is enormous: large-scale studies - including the data behind EPSS and research from the Cyentia Institute - show that only a small fraction of CVEs, on the order of a few percent, is ever actually exploited in the real world. Treating every 9.8 as an emergency means drowning in noise and ignoring the 6.5 that truly affects you.

The industry's answer is a multi-signal prioritization stack: CVSS (how bad) combines with EPSS (Exploit Prediction Scoring System, maintained by FIRST, estimating the probability of exploitation), with CISA KEV (the catalogue of what is actively exploited - the ground truth) and, above all, with your context: do you run that software? Is it exposed to the Internet? Only crossing these signals turns a list of severity into a list of priority.

Sources lie by omission

Then there is a problem upstream, in the raw data. If you rely on NVD alone, your severity distribution is structurally skewed: in my data NVD produces roughly 2% LOW-severity vulnerabilities. Not because LOWs don't exist, but because its scoring process tends to concentrate on high impact. If you build your intelligence on a single source, you inherit its blind spots.

The answer is multi-source by intent, not by accumulation. GitHub Security Advisories brings native severities, including the LOW and MEDIUM that NVD often does not assign. CISA KEV has precise semantics: every entry is an actively exploited vulnerability, so by definition I treat it as CRITICAL, with a flag if it is ransomware-related. Each source is not a copy of the others - it is a different vantage point on the same landscape.

Relevance is context, not severity

This is the heart of the problem, and what Valta was built to solve. A Critical CVE on software you don't run is less urgent than a Medium on a component you expose to the Internet. Absolute severity is only half the story; the other half is context. Valta's engine evaluates every threat against the organization's real profile - the technology stack, the sector, the known attack surface. A large language model does the contextual judgment you cannot encode in a static rule, but on top of it I put a non-negotiable gate: a vulnerability becomes relevant only if there is an explicit match with a product in use or a direct threat to the sector. That gate alone turned a stream full of false positives into a list an analyst trusts enough to read.

Noise is the real bug

The most instructive war story is not technical, it is about design. The first version of the alerting system did the obvious, wrong thing: every threat generated an alert, and every alert was sent to all users by email, with no filtering for organizational relevance. The result was an avalanche of hundreds of emails a day, the vast majority irrelevant to whoever received them. Within a few weeks, people stop reading. An alerting system nobody reads is worse than no system, because it gives a false sense of coverage - it is alert fatigue, one of the best-documented causes of breaches that "the logs had seen but nobody had looked at".

The rewrite introduced two principles. First, relevance gating: an alert only fires if the threat is genuinely relevant to that organization. Second, three tiers instead of one.

I did not add intelligence by generating more alerts - I added it by deciding what not to deliver. It is the difference between a system that informs you and one that helps you.

The details that aren't in the docs

Real engineering lives in the corners, and a CTI pipeline is full of them. Two real examples from integrating with GitHub Advisories. First: the API does not accept an ISO 8601 timestamp to filter by publication date - it wants a range in the form YYYY-MM-DD..YYYY-MM-DD. Pass it a timestamp with T and Z and it fails silently, and you only notice when the counts don't add up. Second: pagination. The temptation is to extract the cursor from the response and rebuild the URL. Mistake: the cursor is already URL-encoded, and the HTTP client encodes it a second time, breaking the query. The correct fix is to use the full URL provided in the Link header, untouched. Tiny details - until they cost you half a day, and until you realize it is exactly in details like these that a pipeline silently loses data.

How to evaluate a threat intelligence platform

• Relevance: does it filter for your profile, or broadcast everything to everyone?
• Sources: is it multi-source, or does it inherit the blind spots of one (the NVD-only problem)?
• Prioritization: does it use EPSS and KEV, or stop at CVSS?
• Context: does it cross threats with your asset inventory?
• Suppression: does it have tiers (immediate / digest / silent) or does it flood?
• Explainability: does it tell you why something is relevant, or is it a black box?

The takeaway

The craft of threat intelligence is not telling you everything that happened - anyone can do that, an aggregator is enough. It is telling you the three things you need to act on right now. The value is not in aggregating, it is in suppressing with judgment: choosing, for each organization and each day, what not to deliver. Build the suppression, not the pile.