A single external and internal scan of a mid-sized environment routinely returns somewhere between 10,000 and 40,000 raw findings once every host, port, service banner, and library version gets checked against a vulnerability database. Almost none of that list is ready for an engineer to act on. Some entries are duplicate detections of the same open port across load-balanced nodes. Some are CVEs that match a version string but not the actual code path in use. Some are real but sit on an asset nobody would ever expose to an attacker. AI triage is the automated step that sits between “the scanner flagged this” and “an engineer should spend time on this.” It does not replace judgment. It replaces the first several hours of manual judgment a human analyst would otherwise spend reading advisories and checking whether each finding is even reachable.
What triage actually means when a scan returns 40,000 raw findings
Triage, in the security operations sense, is a sorting function with three outputs: confirmed risk, informational noise, and needs-human-review. The raw output of a scan pass, whether it comes from Nessus, OpenVAS, Nikto, or a custom SAST run, is not organized around any of those three categories. It is organized around what the scanner’s plugin set happened to check. A finding labeled “critical” by CVSS base score alone tells you almost nothing about whether it is exploitable in your specific deployment, because CVSS base score deliberately ignores environmental factors like network placement and compensating controls.
The practical problem is volume combined with ambiguity. If a team receives 40,000 findings and even 5 percent require a human to open a terminal and check something, that is 2,000 manual investigations. At an average of 10 to 15 minutes per check, a single scan cycle produces multiple person-weeks of triage work before any actual remediation starts. This is the bottleneck that pushes most scan-and-forget programs into the state security teams describe as alert fatigue: the backlog grows faster than anyone can clear it, so the queue gets ignored, and the few findings that matter get lost in the pile. Any platform’s scan management layer can schedule and normalize scanner output, but normalization alone does not solve ambiguity. That is the specific gap an AI triage layer is built to close.
The three jobs an AI triage layer performs: classify, correlate, justify
Effective triage is not one function, it is three distinct jobs that happen to run in sequence on the same finding.
Classify
Classification assigns each raw finding to one of a small set of buckets: true positive requiring action, true positive already mitigated by a compensating control, informational with no action needed, or false positive. A model doing this well reads the finding alongside the advisory text, the detected version, and any available configuration data, then produces a label with a confidence score rather than a binary flag. Low-confidence classifications should route to a human queue instead of being auto-closed or auto-escalated silently.
Correlate
Correlation groups findings that share a root cause. A single outdated OpenSSL library might generate a dozen separate CVE entries across a scan, and a misconfigured load balancer might cause the same finding to appear on six host IPs. Without correlation, a team fixes the same underlying issue six separate times, or worse, closes five duplicates and misses that the sixth instance sits on a different subnet with different exposure.
Justify
This is the step static rule engines skip entirely. A rule engine outputs a label. A triage layer with a justification step outputs a short written rationale: what evidence supports the verdict, what was checked, and what would change the verdict if it turned out to be wrong. This matters operationally because the person who eventually reviews a contested finding, whether that is a security engineer, an auditor, or a manager six months later, needs to know why the system decided what it decided, not just what it decided.
Signals a model reads that a static rule engine cannot: asset role, config state, service reachability
A regex-based or CVSS-threshold rule engine can only act on what is written directly in the scanner’s output. An AI triage layer can pull in and reason over context that lives outside the scan result itself.
Asset role
The same open Redis port means something different on a disposable CI runner than on a production cache holding session tokens. Asset role, whether pulled from a CMDB, a cloud provider’s tagging API, or an inventory maintained inside the platform, changes the actual risk of an otherwise identical finding. Static rules generally cannot express “treat this CVE as critical only on hosts tagged production-database,” because that requires a join across two data sources that most scanners never see together.
Config state
A vulnerable library version is not automatically an exploitable one. If the vulnerable code path is disabled by a feature flag, if TLS 1.0 is technically enabled on a load balancer but no client-facing listener actually negotiates it, or if a debug endpoint returns a 404 because it was removed from routing even though the binary still contains it, the finding is technically true and practically irrelevant. Reading config state means checking the actual running configuration, not just the installed package manifest.
Service reachability
A critical CVE on an internal-only management interface behind a VPN and a firewall rule that permits exactly two source IPs is a different risk than the same CVE on a port open to 0.0.0.0/0. Reachability checks, whether through active network probing, firewall rule analysis, or cloud security group inspection, are what let a triage layer separate “theoretically vulnerable” from “an attacker on the internet can reach this today.” Platforms that automate this phase, such as SITEY, pull exposure and network path data at triage time specifically so severity reflects reachability rather than a static CVSS number alone.
Worked example: one finding traced from raw scanner output to a written verdict
Consider a concrete case. A scan pass reports a CVE against Apache HTTP Server on host 10.0.4.12, port 8443, with a CVSS base score of 9.1. Here is what a triage layer does with that single line before it reaches a human queue.
- Version check. The advertised Server header string is parsed against the vendor’s fixed-version table. If the installed build already contains the backport patch despite an older-looking version string, the finding is downgraded immediately, a common case with distro-maintained packages that backport fixes without bumping the visible version number.
- Asset context lookup. The host is matched against inventory data. 10.0.4.12 turns out to be tagged as an internal staging box for a marketing site, not a production system holding customer data.
- Reachability check. A network path check confirms port 8443 is only reachable from the corporate VPN range, not from the public internet.
- Config check. The specific module required to trigger the vulnerable code path is confirmed disabled in the running configuration.
- Verdict. The system writes a rationale: “CVE confirmed present in installed version. Vulnerable module disabled in current config, exploitation requires the module active. Asset is internal-only, VPN-restricted, non-production. Recommended priority: low, scheduled patch on next maintenance window rather than emergency ticket.” A confidence score accompanies the verdict, and the finding is logged with every piece of evidence used to reach it.
That is six manual steps compressed into one automated pass, with the reasoning preserved rather than discarded. A human reviewer can accept the verdict, override it, or ask for re-verification without redoing the investigation from scratch.
Where AI triage gets things wrong, and the cost of each error type
No triage system, human or automated, has a zero error rate, and the two error types are not equally costly.
| Error type | What happens | Cost |
|---|---|---|
| Over-triage (false positive kept as urgent) | A low-risk finding gets flagged as critical and consumes engineering time | Wasted hours, queue fatigue, lower trust in future flags |
| Under-triage (true positive dismissed) | A genuinely exploitable finding gets classified as informational or auto-closed | Real exposure window left open, potentially undetected until incident |
| Low-confidence auto-decided | The model had weak evidence but still emitted a firm verdict instead of escalating | Both of the above, plus a false sense that the finding was properly reviewed |
Under-triage is the more expensive failure mode because it is silent. A team that over-triages notices quickly, because engineers complain about chasing non-issues. A team that under-triages usually only learns about it after an incident, when someone traces the root cause back to a finding that was closed months earlier with a confidence score that, in hindsight, should have triggered manual review. The operational fix is not to chase a zero false-negative rate, which is not achievable, but to set an explicit confidence threshold below which the system escalates instead of deciding, and to track that threshold’s calibration over time against actual outcomes.
What must be recorded so a verdict can be re-examined months later
Triage output has a second life beyond the immediate remediation decision: it becomes evidence during an audit, an incident postmortem, or a customer security questionnaire. For that second life to work, a few things need to be captured at the moment the verdict is made, not reconstructed afterward.
- The raw finding as reported by the scanner, unmodified, so the original signal is never lost to normalization.
- Every piece of context used in the decision: the asset tag consulted, the config value checked, the reachability test result, with timestamps for each.
- The model or ruleset version that produced the verdict, since logic changes over time and a verdict needs to be attributable to a specific version of the decision logic.
- The written rationale itself, in full, not truncated to a short label. A one-word verdict cannot be second-guessed; a paragraph of reasoning can be checked against what was actually true at the time.
- Any human override, including who made it and what evidence changed their mind.
This record is what makes a vulnerability lifecycle defensible to an ISO 27001 or SOC 2 auditor: not that every finding was fixed, but that every decision, including the decision to not fix something immediately, has a traceable justification. It is also what makes re-testing meaningful. When a fix is deployed and a finding moves through retest and closure, the original evidence trail is what confirms the closure addressed the actual condition that was flagged, rather than closing the ticket on faith that a patch command returned a zero exit code. Teams evaluating an AI triage layer for their own environment should ask specifically whether verdicts are stored with full rationale and evidence, or only as a final label, because the label alone is not enough when someone has to answer for a decision a year after it was made.
About SITEY
SITEY is an autonomous vulnerability management platform. It discovers, validates, prioritizes, remediates and re-tests vulnerabilities through an eight-phase automated pipeline, unifying output from 17 integrated scanners. SITEY is self-hosted: it runs in your own infrastructure and your findings are stored there. Outbound connections are limited to licence activation and the optional services you enable, such as an AI provider, CVE enrichment and patch catalogues. Pricing is 599 USD per month or 5,999 USD for a perpetual lifetime license. See pricing or how the platform works.