Triage findings
A scanner that reports 400 issues is not helping you. This guide shows how to turn a raw findings list into a short, ranked to-do list you can actually work through.
Start with priority, not severity
Severity tells you how dangerous a vulnerability is in theory. Priority tells you what to do about it in your environment, factoring in whether it's being exploited in the wild and whether the affected asset is exposed.
Sort the Findings list by priority and work top-down:
- Act first: actively exploited or high-impact and internet-facing. These are the ones attackers are using right now.
- Attend next: real and worth scheduling, but not on fire.
- Track / Track* last: record and revisit; don't let them crowd out the top of your list.
A critical-severity finding on an internal, unexploited service can rank below a medium-severity one that's being exploited on your public site. That's the point: priority sends you to the work that reduces real risk fastest.
Trust the noise filter, and check it occasionally
Horus hides "absence-of-vulnerability" output and informational chatter by default so your list stays signal-heavy. You'll see a "N hidden" banner.
- Day to day, leave it hidden.
- If you're chasing something specific and want the raw picture, click the banner to reveal noise. Nothing is deleted; it's always retrievable.
Resolve, dismiss, or accept
Every finding should end in one of these states. Setting them is not just bookkeeping: your verdicts train Horus to handle similar findings automatically next time.
| Status | Use it when |
|---|---|
| resolved | You fixed it. Re-scan to confirm it's gone. |
| false_positive | It isn't real (wrong version match, unreachable service, already mitigated). |
| accepted_risk | It's real but you've made a deliberate decision to live with it. |
| open | Still needs work. |
Select multiple findings and use the bulk action to apply the same status at once, e.g. dismissing a batch of confirmed false positives.
Use the suggested fix
Open a finding to see AI-drafted remediation: an action type (update a library, patch a config, rotate credentials), numbered steps, and often the exact command or config snippet. It's tailored to whether the asset is internal or external, so the advice fits the context.
Copy the steps, apply them, mark the finding resolved, and re-scan to verify.
Promote real work to incidents
For anything that needs more than a quick fix (multiple related findings, an owner, a deadline), create an incident:
- Link the related findings together.
- Assign an owner and an SLA deadline.
- Track progress with append-only notes so there's an auditable history.
This keeps the findings list about detection and the incidents list about the work in flight.
Why a finding survived (or didn't)
When a finding is genuinely ambiguous, Horus runs an adversarial check: one perspective argues it's real and exploitable, another argues it's a false positive, and a verdict is recorded with the reasoning. You can read that reasoning on the finding.
Clear-cut cases skip this entirely: known-exploited vulnerabilities are auto-confirmed, and trivial noise is auto-dismissed. So when something reaches your Act list, it has already survived scrutiny. Full detail: how the pipeline works.