← All articles

Threat intelligence in a build pipeline

August 7, 2026 · Wilson Santos
threatsthreat-intelligencevirustotalsupply-chaindevsecops
On this page

Threat intelligence has a scale problem when it meets a build pipeline.

The feeds are enormous and built for a security operations center, millions of indicators, refreshed constantly, meant to be correlated against network traffic by people whose job that is. Point that at a CI job and you get either everything or nothing useful, and teams reasonably conclude the category does not belong in a pipeline.

It does. It just has to be pointed at something specific.

The question nothing else answers

Every other control examines something you run. Your source, your dependencies, your configuration, your headers, your certificate. All of it is inward. It inspects what you built.

Threat intelligence is the only one that looks outward: what has somebody else already observed about this thing?

Five controls read inward, one reads outward Static analysis, dependency scanning, misconfiguration, headers and certificates all examine the thing you built, using only what is in front of them. Threat intelligence sends the hosts and images your descriptor declares to a reputation database and reports what somebody else has already observed about them. READS WHAT YOU BUILT sastscaiac headerstls what you built all the evidence is already here 6 hosts, 2 images ASKS SOMEBODY ELSE threats what the outside world has already seen A scanner cannot find what is not in front of it. Somebody else may have been watching for weeks.
The others answer from the material you handed them. This one is the only place a report can learn something you did not already have.

That is a different question, and it catches a different class of problem. A scanner pointed at your own endpoint checks the paths you know about. It cannot tell you that a directory on the same host has been serving malware for three weeks, because you never told it to look and nothing in your code mentions it.

If something on your infrastructure has been compromised and put to work, the outside world usually knows before you do. That knowledge is public, and free.

Why narrow scope is the whole trick

The difference between useful and noise is what you match against.

Broad

Ingest a feed, compare it to everything, alert on hits. A SOC function. It needs tuning, staffing and a tolerance for false positives, and it cannot return a verdict before a merge.

Narrow

Ask whether any of the handful of hosts and images your descriptor already declares appears in a reputation database. A small number of lookups, a binary answer, and any hit worth somebody's attention at once.

The second is the one that belongs in a pipeline, and it is only possible because something already declared what "yours" means. Without that list, there is nothing to scope to, which is why this control is hard to bolt onto a generic scanner and straightforward when a descriptor exists.

The awkward parts, said plainly

These are hosted services with terms

URLhaus and VirusTotal both have rules about commercial use and rate limits on free keys, and VirusTotal's public tier is explicitly non-commercial. A key issued in thirty seconds still comes with a contract, and free does not mean unrestricted. Read the terms before wiring either into a build that runs for a company.

Something leaves your network

A reputation lookup sends an identifier to a third party. Usually a hostname you publish anyway, so the disclosure is small, and it is not zero. Any control that talks to somebody else should say so before you switch it on, so that enabling it is a decision rather than a default.

A hit is not a verdict

Reputation data carries false positives, stale entries and shared infrastructure. Your host on a CDN address something else abused is a different situation from your host serving something itself. Treat a hit as a reason to look rather than a finding to gate on.

Where it sits

This is a low-frequency, high-signal check. It rarely fires. When it does, it usually matters more than anything else in the report, because it is evidence of something that has already happened rather than something that could.

Draugr's threats control looks up the hosts and images a component declares, using URLhaus by default and VirusTotal opt-in. Both scanners document their terms and what is sent, because a control that discloses something should say what and to whom before you switch it on.

The threat intelligence guide covers the data sources and their limits.