Pulseguard
Under Attack?Threat Intelligence
Signal, not a pile of alerts.
Ten findings are rarely ten problems. Correlation groups them by the misconfiguration underneath, then ranks the groups by severity, confidence, and whether anything is actually reachable from the internet, so the top of the list is genuinely the thing to fix first.
- Grouping, not severity alone
- Root cause
- Behind every priority score
- 5 inputs
- Severity and priority
- Both shown
- When priority is computed
- At detection
Ten alerts, three actual problems.
Hover a cause to see which findings collapse into it. The queue on the right is what your morning looks like once they do.
Three subdomains resolve straight to the origin IP, bypassing the edge entirely.
The same six pages are missing CSP, HSTS, and Referrer-Policy: one shared template, not six problems.
Two certificates issued by hand after the last renewal failure, both now inside the expiry window.
Ranking is a product decision, not a sort order
A critical finding nobody can reach matters less than a medium one on your login page. Anything that hides that is making the decision for you badly.
Grouped by cause
Six pages missing a header aren't six problems. They're one template. Correlation says so, and the fix count drops accordingly.
Exposure changes the ranking
Priority is computed from severity, confidence, whether the asset is publicly exposed, whether it sits behind authentication, and how many pages it affects. Reachability is part of the maths, not a footnote.
Severity is never hidden
Priority and severity are always displayed together. A critical-but-unreachable finding can rank below a medium-but-exposed one without ever stopping being critical.
One view across everything
Scanner findings, DNS drift, certificate expiry, and edge activity land in the same model, so correlation works across your whole footprint rather than per tool.
Recurrence is a signal
Every re-detection is recorded as an occurrence against the same finding. Something that keeps coming back after being fixed reads differently from something detected once.
Stored, not recomputed
The priority score is written at detection time, so the ranking you saw in an incident review is the ranking that existed then, not whatever today's weighting would produce.
Five inputs, no black box
Every component of a priority score is a field you can read on the finding. If the ranking surprises you, the reason is visible.
Severity
The intrinsic seriousness of the issue, assigned by the rule that detected it and never adjusted by ranking.
Confidence
How certain the detection is, lowered per-project when you mark a rule's findings as false positives.
Public exposure
Whether the affected asset is reachable from the internet: the single biggest difference between a theoretical and an exploitable issue.
Blast radius
How many pages or assets the same finding affects, which is what separates a one-page oversight from a site-wide default.
Auth requirement
Whether reaching the affected surface requires a login, recorded per endpoint as it's discovered.
Occurrence history
Every scan that re-detected the finding, kept as its own record so regression after a fix is visible rather than inferred.
From raw detections to an ordered queue
Correlation runs as part of the scan pipeline, on data that has already been captured and verified.
- 1
Findings arrive in one shape
Every rule (headers, TLS, cookies, secrets, DNS, disclosure) returns through the same builder, with severity, confidence, evidence, and the affected asset. Correlation is only possible because nothing gets to be a special case.
- 2
The scan is diffed against the last one
New, still-present, and resolved findings are separated, and score deltas per category are computed, and that diff is gated so a project's first scan is treated as a baseline rather than a flood of new issues.
- 3
Related findings collapse into a cause
Detections sharing a rule, an asset, or an origin are grouped, so a policy that was never deployed reads as one item with a count rather than as one row per page.
- 4
Each group is scored and ordered
Severity, confidence, exposure, auth requirement, and affected-page count produce the priority score stored on the finding, and the queue is ordered by it, with severity still shown beside it.
- 5
The serious ones become incidents
A newly introduced critical or high finding opens an Incident with its own Open → Investigating → Monitoring → Resolved timeline, so the top of the queue turns into tracked work automatically.
Threat Intelligence, answered.
No. It's intelligence about your footprint, built from your own scan results: correlation and prioritisation of findings PulseGuard detected and captured evidence for. It doesn't resell a third-party indicator feed or claim knowledge of attacks it hasn't observed.
Work the list from the top.
Run a scan and see what your findings look like once they're grouped by the thing actually causing them.