ThreatPulse asks one question: is this scary for us?

Open a security news feed on any weekday morning and a couple hundred fresh stories are already waiting. A ransomware crew hit a hospital chain overnight. A popular open-source library turned out to be backdoored. Somebody's customer records are for sale again. And every single one of them arrives dressed as an emergency: critical, urgent, act now. That's the trap of security news. The volume is enormous, everything looks important, and when everything is critical, nothing is. So the question a security leader actually carries into the office is not "what happened in security today." It's simpler, harder, and a little selfish: sure, it's important. But is it important to us?

ThreatPulse is a tool I built over five weeks to answer that question for one large enterprise. Every weekday morning it reads roughly 200 to 250 security news items from about 50 sources, decides which of them actually touch this specific organization, and posts a short briefing to Slack: an executive summary anyone can read in a minute, and a technical thread underneath for whoever needs the details. On a typical day, three to twelve items make it in. Everything else gets read, judged, and set aside.

Here's roughly what lands in the channel, with every name and number invented:

Most "threat intelligence" answers the wrong question

Inside most companies, the thing called threat intelligence is really a vulnerability feed wearing a costume. It's a list of CVEs, the catalogue numbers assigned to software flaws, sorted by a severity score, and it leaves the reader to figure out which of several hundred entries actually matter. That's a useful function, but it's patch management. It answers "what is broken," not "who is coming for us."

ThreatPulse flips it. The briefing leads with what's emerging, the attacker side of the news: phishing and credential-theft campaigns running right now, the named groups behind them, the fraud patterns aimed at this kind of business specifically, breaches at similar companies, and break-ins at vendors whose software the organization runs. A flaw in the company's own tech stack only makes the briefing when someone is actively exploiting it in the real world. Everything else gets dropped, and the briefing says how many it dropped and points to the patching team as the owner. That detail matters more than it looks. A tool that quietly ignores things looks broken. One that says "seven advisories deferred to patch management today" looks deliberate, and it keeps the peace with the team whose job that actually is.

It also makes the handoff useful in both directions. Vulnerability management answers "what is broken" better than any briefing ever will. What it drowns in is prioritization, a queue several hundred advisories deep with no way to know which one just caught fire. So when a stack flaw does clear ThreatPulse's bar, it arrives framed as an active threat with the evidence attached: not one more row in the queue, but this one, today. That split makes both sides better. The patching program gets a fire alarm instead of another list, and the intelligence side, freed from re-listing every CVE, only ever cries wolf about actual wolves. That's what keeps the briefing believable, and believability is the entire product.

"Us" is the hard part

A burglary three states away is a news item. A burglary on your street is a warning. Same event, completely different meaning, and the difference is entirely a matter of where you live. For "is this scary for us" to mean anything, ThreatPulse has to know where the company lives.

So underneath everything sits a machine-readable picture of the organization itself. The products and vendors it runs, ranked by how much they matter. The brand names criminals impersonate in phishing. The business processes fraud actually goes after. Every story gets checked against that picture, and a story is relevant because it touches something in it, not because it's big security news. The exact same headline, about a company that runs different software and holds different data, stays in the background.

This is the whole difference between news and intelligence. News tells you what happened. Intelligence tells you what it means for you, and there is no computing "for you" without a model of who you are.

Fourteen stages between the internet and your morning coffee

Here's what actually happens before that Slack message lands. Early in the morning, ThreatPulse wakes up and does the reading nobody wants to do. It pulls from around 50 sources: security vendor blogs, news outlets, research teams, government advisories, an industry sharing group, a feed that tracks compromised software packages. It greets each one with the only question that matters between old friends, what's new since yesterday, so it never re-reads what it has already seen. Then it puts everything in the same outfit. Fifty sources means fifty opinions about what a news item should look like, and stage two politely disagrees with all of them: every item becomes a title, a body, a timestamp and a source, no matter how it arrived.

Next it plays matchmaker. Six outlets, six different headlines, one actual event. Related articles get grouped into a single story that carries all its sources, and stories are remembered from one day to the next, so a campaign that develops over three days is one story with three days of history rather than three fresh alerts. This grouping quietly earns its keep twice. A reader sees each event once instead of six times, because a briefing dies the day people start skimming it. And independent outlets reporting the same thing is what confirmation means, so the pile of sources under a story is also where the "how sure are we" answer comes from.

Then the homework. Every software flaw a story mentions gets checked against outside ground truth: the official record, an exploit-prediction score, and whether it sits in the government's catalogue of flaws confirmed as exploited in the wild. "Actively exploited" in this system is a fact you can look up, not a vibe. Compromised package names get checked against what's actually installed on the organization's developer machines, a check we'll come back to, because it's the best thing in the whole system. Only now does a language model get its first turn: for each story, one structured judgment. Which channel does this belong to, how bad is it, how sure are we, and what in the company's own profile does it touch. A second model then reviews everything the first one dismissed, and this reviewer has a deliberately strange job description: it is only allowed to rescue stories, never to bury them. An appeals court that can pardon but not convict.

The decision about what you actually see belongs to none of the models. It belongs to a bouncer, and the bouncer is code. Fraud campaigns, vendor breaches and peer incidents walk straight in. Stack flaws get in only with evidence of active exploitation, and the rest are counted and shown the door with a polite referral to patch management. Yesterday's story doesn't get to reintroduce itself unless it has something genuinely new to say. Then the prose gets written, mad-lib style, more on that in a minute, and a fact-checker with scissors goes through it: any sentence that can't point at its supporting evidence gets cut, and the cut is written down. Finally the briefing is assembled and posted, once. Run the whole machine twice by accident and you still get exactly one briefing, because it knows it has already spoken.

"Scary" is two questions, not one

Early on, the tool made a mistake that taught me something. A fraud campaign was rated high severity the day it broke. The next day, after two more outlets wrote up the same story, it came back rated medium. That's exactly backwards. Nothing about the threat had improved overnight. The story had been confirmed by more sources, and the tool treated confirmation as a reason to relax.

The mistake underneath is treating two questions as one: how bad is this, and how sure are we about it. A hurricane forecast keeps those dials separate for a reason. The storm's category and the forecasters' confidence in its track are different numbers, and a category five with an uncertain path is still a category five. More reports agreeing on the path don't weaken the storm. They firm up the warning.

Mix the two and you fail in both directions. A genuinely dangerous report from a single source gets quietly downgraded, so you're under-warned about the one thing that mattered. A trivial story covered by five outlets gets inflated, so you're alarmed about something that never deserved it. ThreatPulse keeps them apart: how bad something is only changes when there's new information about the threat itself, while how sure we are moves freely as sources come in. And in the text a reader sees, uncertainty shows up as honest hedging about the sourcing, never as a reason to downplay. "Unconfirmed, but consistent with the fraud we already defend against" is the right sentence. "Unconfirmed, so probably ignore it" is not, because the item was only selected in the first place because it matters.

The scariest answer is "yes, and it's in the house"

The most useful thing ThreatPulse does is also the easiest to explain. When a supply-chain attack compromises a set of software packages, the tool takes those package names and checks them against a live inventory of what's actually installed on the organization's developer machines. "This package was backdoored" is news. "This package was backdoored, and it's sitting on machines here" is an exposure finding. It's the difference between reading about the storm and finding water in your basement, and it's the question in the title answered at its most literal.

It has fired for real. During a live supply-chain worm, several of the compromised packages turned out to be present in our own inventory, across several thousand developer machines. And one honest caveat travels with that finding every single time it appears: the inventory knows a package is present, not which version of it is installed. So the finding means "the name is here, on up to that many machines," not "that many machines are compromised." That difference is what separates a useful early warning from a false alarm, and being precise about it is part of why the briefing can be believed.

What that does to the clock

Security programs get judged on two clocks. Mean time to detect, MTTD, is how long something is wrong before you know about it. Mean time to respond, MTTR, is how long you know before you act. And what makes an emerging threat emerging is that its clock just started: the campaign began this week, the package was compromised yesterday, the flaw tipped from theoretical to actively exploited overnight. Those are exactly the situations where every day of lag is a day of exposure.

I can't hand you a before-and-after MTTD chart from five weeks of runs, and I'd side-eye anyone who could. What I can tell you is where the design takes the time out. On the detect side, the daily rhythm puts a hard ceiling on lag: anything the sources report is inside the building by the next morning's briefing, already checked against what the organization runs and what's installed on its machines. The supply-chain check is the sharpest version of that. The morning the worm story broke, the question that matters most, is it in our house, was answered in the same run, automatically, as a check nobody had to remember to ask for. On the respond side, the briefing starts the queue at the right end. It leads with what's actively exploited and actually relevant, keeps yesterday's unchanged stories out of the way, and puts affected products, exploitation status and the indicators a defender pivots on in the thread right underneath. Whoever picks it up starts with a pivot point instead of a search box.

Keeping the AI part honest

You may have noticed the model only got a say in four of those fourteen stages: the classifier, the critic, the writer, and the fact-checker at the end. That ratio is the point. For a briefing, a made-up number or a made-up identifier is worse than silence, because one invented detail poisons the reader's trust in everything else on the page. So every decision about what a reader actually sees is made by ordinary, checkable code, and the model works inside fences.

The writing step is essentially a mad-lib. The model gets each story with every number, date and identifier replaced by a blank, writes its sentences around the blanks, and ordinary code fills in the true values at the end from the stored facts. It cannot invent a number because it never sees one. I learned the hard way that asking a model nicely not to do something it can plainly see how to do does not work. It kept copying the real digits anyway, politely, twice. What worked was removing the temptation entirely.

Where it goes next: from warning to hunt

Under every briefing, the technical thread already lists the fingerprints an attack leaves behind: the domains it calls home to, the IP addresses it comes from, the file hashes of its malware. Security people call them indicators of compromise, IOCs. Today they're printed defanged, so nobody clicks one by accident, and handed to a defender to chase by hand. The phase I planned next closes that loop, because a company's logs are the closest thing it has to camera footage of its own network. Take every indicator the briefing surfaces and sweep it through whatever log platform is already watching, a Splunk, an ELK stack, anything that can answer one question fast: have we seen this before?

That would complete the ladder the whole tool climbs. Is this campaign real? Does it touch what we run? Is the poisoned package in our house? And the last rung: has any of it already been here? A briefing item with a log hit would stop being intelligence and become an incident, with a timestamp attached, and the morning post goes from worth reading to start here. Nobody begins at the search box, because the search already ran. The same honesty rules would apply as everywhere else, too. A clean sweep means the logs don't show it, not that it never happened, the same way the inventory check says name present, version unverified, instead of pretending to certainty it doesn't have.

Where it's still honest about falling short

The best real finding it ever produced never reached a reader through the tool. The supply-chain match fired a day before the screen that displays that kind of finding existed, and by the following morning the story was old news to the system, so it correctly stayed quiet. The finding got to the security team through a plain human message instead. Missed by one day, and I'd rather say so than pretend otherwise, because a briefing tool's entire value is that you can believe it.

That's really the whole idea. The point was never to build something that knows everything about security. It was to build something that can answer a single question every morning, is this scary for us, and be worth believing when it says yes.