Threat intelligence in a build pipeline: useful only when it is narrow

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?

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. This is a SOC function. It needs tuning, staffing and a tolerance for false positives, and it does not fit in a job that has to return a verdict before a merge.

Narrow: take the handful of hosts and images your descriptor already declares, and ask whether any of them appears in a reputation database. That is a small number of lookups with a binary answer, and any hit is worth a human's attention immediately.

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 are the obvious sources, and both have rules about commercial use and rate limits on free keys. VirusTotal's public tier is explicitly non-commercial. Read the terms before wiring either into a build that runs for a company, a key issued in thirty seconds still comes with a contract, and it is easy to miss that free does not mean unrestricted.

Something leaves your network. A reputation lookup means sending an identifier to a third party. Usually a hostname you publish anyway, so the disclosure is small, but it is not zero, and it deserves to be a deliberate choice rather than a default. Any control that talks to somebody else should say so before you enable it.

A hit is not a verdict. Reputation data has false positives, stale entries and shared infrastructure, your host on a CDN address that something else abused is a very different situation from your host serving something itself. Treat a hit as a reason to look, not as a finding to gate on blindly.

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.