Running Nuclei at scale: correlation, de-duplication, and taming false positives

Nuclei is one of the best things to happen to practical security in years: a fast, templated scanner with a community library covering thousands of CVEs, misconfigurations, exposures, and takeovers. If you’re doing external security work and you’re not using it, start today.

But there’s a difference between running Nuclei and operationalizing it. Fire it once at a handful of hosts and it’s magic. Point it at a real, continuously-growing attack surface every single day and you discover the unglamorous truths that separate a demo from a program.

The problems that show up at scale

Volume without memory. Run Nuclei daily and yesterday’s findings come back today — the same info-level exposure, the same self-signed cert warning, the same thing you already looked at. Without state, every run re-reports everything, and real changes drown in the repetition.

False positives and severity inflation. The template library is broad and community-driven, which is its strength and its tax. Some templates are noisy, some severities don’t match your context, and a wall of mediums with no prioritization is indistinguishable from a wall of nothing.

No cross-tool correlation. Nuclei sees what Nuclei sees. The weak TLS it flags is the same weakness tlsx flagged and the same one in your httpx notes — three rows for one problem, triaged three times.

Template hygiene. Templates update constantly. Pin nothing and results shift under you; pin everything and you miss new detections. Someone has to own that.

Rate and blast radius. Aggressive settings get you rate-limited, blocked, or — worse — into trouble with the target. Conservative settings miss things. The right answer is per-target, time-windowed, and authorized.

What operationalizing it actually requires

None of these are reasons not to use Nuclei. They’re the work around Nuclei that turns raw output into findings you can act on:

• De-duplicate across engines and over time. Collapse the same issue — from Nuclei and every other tool — into one finding with a stable identity and a full occurrence history. Triage it once.
• Correlate to persistent assets. Tie every detection to the host it lives on, so you can answer “what’s wrong with api.example.com” instead of grepping JSON.
• Normalize severity. Map Nuclei’s ratings onto a consistent, CVSS-aligned scale so you can threshold alerts and actually sort by what matters.
• Persist triage and detect regressions. A finding you accepted stays accepted; a “fixed” finding that reappears gets flagged as regressed.
• Run it safely. Per-engine rate limits, intensity caps, time windows, and authorization — so the scan is both effective and defensible.
• Report the delta, not the dump. Each run’s signal is what changed, not the full re-listing.

Don’t rewrite the engine — build the layer around it

The mistake teams make is deciding Nuclei “isn’t enough” and going looking for a different scanner. The engine is rarely the problem. The missing piece is the orchestration, correlation, and reporting layer that makes its output operational — the stuff you’d otherwise hand-build in scripts and slowly drown maintaining.

That layer is exactly what ProbeIQ is: the connective tissue over Nuclei and the rest of the ProjectDiscovery suite, so you get correlated, de-duplicated, prioritized findings instead of a nightly firehose. If that’s the glue code you’ve been meaning to write, let us show you.