Vulnerability threat intelligence & AI: How Holm Security builds tests

Holm Security uses AI to draft vulnerability tests from vulnerability threat intelligence, and our Security Research team validates every one before it reaches your environment.

Somewhere right now, a researcher is publishing the details of a vulnerability that nobody knew about yesterday. A CVE number gets assigned, the advisory goes live, and from that moment the clock is running for every organization using the affected product.

Between that advisory going live and the vulnerability showing up in anyone's report, there's a piece of work most people never see. A disclosure is not a detection. Someone has to build the test, the piece of logic that checks whether this specific weakness is present on this specific asset. How quickly that happens is one of the more useful things to understand about your vulnerability management platform.

Closing that window is most of what our Security Research team does, and it's where AI has changed how we work. Here's how it runs, from a disclosure somewhere on the internet to a validated test in your environment.

The first day of a vulnerability

It helps to follow a single vulnerability through its first twenty-four hours, because the timeline is rarely as tidy as people assume.

It surfaces somewhere, and that somewhere isn't always an official database. It might be a vendor advisory, a thread on a security forum, or a write-up in a security news outlet hours before the databases catch up. Within a day, proof-of-concept code can appear publicly, which changes the picture completely. Within a week, the same vulnerability might be showing up in ransomware campaigns.

Now multiply that by the hundreds of other vulnerabilities doing exactly the same thing on the same day. That's the actual problem we're solving. It's the volume, arriving continuously, while cybercriminals use AI to find and exploit vulnerabilities faster than ever.

Where we look: 30+ vulnerability intelligence sources

Our Security Research team monitors more than 30 sources. No single one is both fast enough and complete enough to rely on by itself, so the coverage must be wide before it can be fast. Our sources include:

Official and government sources

• CISA Known Exploited Vulnerabilities (KEV) catalog
• National Vulnerability Database (NVD)
• CVE.org
• European Union Vulnerability Database (EUVD)
• National CERTs

Vendor sources

• Vendor security advisories

Exploit sources

• Metasploit
• Exploit-DB

Community intelligence

• Vulmon
• Vulners

Security news & forums

• BleepingComputer
• The Hacker News

The mix matters more than the count. Researchers often discuss a vulnerability on a forum before a database describes it properly. Public exploit code can turn a routine finding into the most urgent item on the list overnight. CISA KEV plays a different role, because it tells you the vulnerability isn't theoretical and is already being used against real organizations.

How we decide what gets tested first

Severity on its own turns out to be a poor way to order the queue, and anyone who has worked through a long vulnerability list already knows why.

A critical-rated vulnerability that nobody is exploiting, in a product almost nobody runs, matters less than a medium-rated one that ransomware operators are actively using this week. That gap between how bad something could be in theory and what is happening in practice is the difference between scoring vulnerabilities and understanding your real risk exposure. It's the entire idea behind risk-based vulnerability management.

Our triage weighs exploitation more heavily than score. We look at whether the vulnerability appears in CISA KEV, whether working exploit code is publicly available, whether it is associated with ransomware activity, and how widely the affected product is actually deployed.

People sometimes frame this as the CVSS versus EPSS debate, but in daily practice neither score replaces knowing what's being used against organizations right now.

Building the test

Once a vulnerability reaches the front of the queue, the work gets specific fast. The affected product and version range have to be pinned down. The detection method must be chosen, and the test has to identify the vulnerability reliably without disrupting the asset it's checking.

This is where AI does the heavy lifting. It reads advisories, extracts the affected versions, drafts the test logic, and absorbs the volume that would otherwise sit in a queue for weeks waiting for a human to get to it. What comes out of that process is a draft.

Validating the test

Every test is checked automatically, then a researcher reviews it before release. The most important check compares the test against the vendor advisory it came from. Errors nearly always show up as a version range that is slightly wrong, so the test flags systems that are already patched or misses ones that are still vulnerable. Those tests are corrected and checked again before they go anywhere.

Tests that actively exploit a vulnerability also run against a real vulnerable system in our lab. We release them only once they have found the vulnerability on that system and reported nothing on an identical system where it has been fixed.

A researcher decides whether a test is ready to release. They read the advisory and the test together, judge whether the detection logic is right, and sign it off.

What AI does & what people do

The division of labor is that AI handles scale and people handle judgment. AI watches every source continuously, pulls structure out of advisories written in a dozen different styles, drafts tests, and flags what looks urgent. It’s work that used to limit how fast any research team could move.

People still decide when a draft test is wrong, work out why a device in the real world responds differently from what the advisory describes, and build the tests for products where the documentation is thin, outdated, or contradicts itself.

What this means for your vulnerability report

Two organizations can run the same kind of platform, hold the same list of assets, and still end up with different pictures of their risk. The difference is rarely the assessment itself. It's how quickly a newly disclosed vulnerability becomes something the platform can actually look for, what decides which ones get covered first, and how much of that work someone has checked before it reaches you.

None of this usually gets written down anywhere a buyer can read it, which is the main reason we wrote it down here. It's worth knowing what sits behind the number on your dashboard, whoever produces it. Three questions are worth asking when you're next comparing exposure and vulnerability management platforms, or renewing one:

• Where does the vulnerability intelligence come from?
• What decides which vulnerabilities get covered first?
• Who checks that a test works before you rely on it?

Want to see how Holm Security finds and prioritizes new vulnerabilities across your assets? Watch our demo video.

FAQ

1. What is vulnerability threat intelligence?

   Vulnerability threat intelligence is the information that tells you which vulnerabilities matter right now: what has been disclosed, what is actively being exploited, whether working exploit code is public, and which of your assets are affected. It's what turns a long list of findings into a defensible priority order.
   
   

2. Which sources does Holm Security monitor?

   More than 30, including CISA KEV, NVD, CVE.org, EUVD, national CERTs, vendor advisories, Metasploit, Exploit-DB, Vulmon, Vulners, and security news outlets and forums such as BleepingComputer and The Hacker News.
   
   

3. Does AI write the vulnerability tests?

   Yes, AI drafts them and does the repeatable analysis behind them, but we validate every test before it goes live. Our Security Research team handles the manual analysis, the product-specific work, and the cases automation can't cover.
   
   

4. Why not just use the CVSS severity score?

   Severity describes how bad a vulnerability could be, not whether anyone is exploiting it. A medium-severity vulnerability being used in active ransomware campaigns is a more urgent fix than a critical one that nobody is exploiting.