Understanding Hunts
Anatomy of a hunt — what it contains, how it moves through statuses, and what outcomes mean.
A hunt is a single proposed test, scored, scoped, and ready to fire with one click.
Anatomy of a hunt
Title and rationale
A short title naming the vulnerability class, plus a paragraph explaining why CodeWall thinks it might apply to you. The rationale references the source signal — a specific CVE, a parent finding, an asset's tech stack — so you can sanity-check the logic before running.
Objective
A precise statement of what the agent should attempt during the run. Hunts are deliberately narrow: "test the /api/users/{id} endpoint for IDOR by enumerating sibling identifiers under the same auth context", not "check the API for authorisation issues". Narrow scope means fast, cheap runs.
Severity
Inherited from the source signal — typically the CVE's CVSS-derived severity for CTI hunts, or capped at the parent finding's severity for variant hunts. Critical and High proposals trigger email alerts (configurable; see Settings).
Affected assets
The specific assets the run will target. Hunts are scoped — the agent will refuse to probe anything outside the affected list, so you know exactly what's getting tested.
Suggested skills
Tactical hints to the agent about which testing techniques to apply (e.g. "ssrf-probe", "idor-enumeration"). Generated alongside the hunt; the agent picks them up automatically when you click Run.
Source
Tells you where the hunt came from — see Hunt Sources for what each source catches and how the signal is generated.
Priority score
A composite ranking that combines severity, source freshness (a brand-new KEV entry scores higher than a 6-month-old NVD record), and asset criticality (crown-jewel assets boost the score). Use this to triage when you have a long queue.
Lifecycle
A hunt moves through a small set of statuses:
| Status | Meaning |
|---|---|
| Proposed | Newly created. Awaiting your review. |
| Running | You clicked Run; the agent is executing the scoped test. |
| Completed | The run finished. See the outcome for what happened. |
| Dismissed | You marked it as not worth running, with a reason. |
| Archived | Auto-archived after the configured retention window with no action. |
Outcomes
When a hunt completes, it carries an outcome:
| Outcome | Meaning | What you do |
|---|---|---|
| Confirmed | The vulnerability is real and a finding has been created. | Triage the finding like any other — see Findings. |
| Not Vulnerable | The agent attempted the exploit and the system held. | Trust the verdict; the test ran and didn't land. |
| Inconclusive | The agent couldn't reach a clear yes/no — usually because of an environmental block, missing credentials, or a rate limit. | Read the run notes and decide whether to retry with broader scope or different inputs. |
Hunts and findings
When a hunt confirms a vulnerability, the resulting finding is stamped with the originating hunt id. Every confirmed finding from a hunt links back to:
- The source intelligence that triggered the hunt (e.g. CVE-2024-46982)
- The rationale CodeWall used to flag it as relevant to your stack
- The full agent run that produced the proof-of-concept
This means audit trails for hunt-sourced findings are richer than for tests — you don't just see what was found, you see why CodeWall went looking.
How hunts get into the queue
Hunts are generated automatically by the platform — you don't request them. Six signals feed the queue (learn more):
- New entries in CISA's Known Exploited Vulnerabilities catalogue
- New CVEs from the National Vulnerability Database
- New GitHub Security Advisories
- Variants of any verified finding ("the same bug, different surface")
- AI analysis of your assets' tech stack
- A daily LLM review pass over your full attack surface
Each hunt the platform proposes has already been pre-filtered against your specific tech stack. CVEs that obviously don't apply — Citrix advisories when you don't run Citrix, Windows kernel bugs on a pure-cloud stack — never reach your queue.