CodeWallDocs
Hunts

Hunt Sources

The six signals CodeWall uses to propose hunts, and what each catches.

Every hunt has a source that explains where its hypothesis came from. There are six source kinds, grouped into three families: threat intelligence (CTI), prior findings, and asset analysis.

Threat intelligence (CTI)

CodeWall continuously ingests three upstream feeds and matches each new entry against your asset narratives. When a CVE plausibly applies to your stack, you get a hunt.

Pre-filtering happens before anything reaches your queue: a CVE for software you don't run never gets proposed. The matcher uses both deterministic vendor/product signatures and AI-driven stack-fit analysis, so it catches cases where you transitively depend on an affected component (e.g. Next.js bundling React, Supabase shipping PostgREST).

cti_kev — CISA Known Exploited Vulnerabilities

Signal: CISA's KEV catalogue lists CVEs that are currently being exploited in the wild. Entries land within days of CISA confirming active exploitation.

Why it matters: KEV is the highest-confidence "you should test this now" signal in the industry. Federal agencies are mandated to patch KEV entries within strict deadlines under BOD 22-01.

Update cadence: Polled hourly.

Typical hunt: "CVE-2024-XXXXX in Citrix NetScaler is being actively exploited. Your asset gateway.example.com shows NetScaler indicators — verify whether the unpatched code path is reachable."

cti_nvd — National Vulnerability Database

Signal: The NVD is the comprehensive US government CVE database — every published CVE flows through it with structured CPE (vendor/product/version) data.

Why it matters: Wider net than KEV. Catches vulnerabilities long before they're seen in the wild — useful for staying ahead of opportunistic scanners.

Update cadence: Polled every four hours.

Typical hunt: "CVE-2024-XXXXX is a stored XSS in WordPress 6.x affecting plugins X, Y, Z. Your asset blog.example.com is running WordPress and the affected plugin pattern matches."

cti_ghsa — GitHub Security Advisories

Signal: GHSA covers the open-source ecosystem — npm, pip, RubyGems, Maven, Cargo, Composer, Go modules, and more.

Why it matters: Application-layer dependencies turn over fast. Many real exploit paths come from a transitive package update, not from infrastructure CVEs.

Update cadence: Polled daily at 02:00 UTC.

Typical hunt: "GHSA-xxxx-xxxx-xxxx is a prototype-pollution issue in lodash@<4.17.21. Your asset's tech narrative indicates a Node.js application; this hunt verifies whether a vulnerable lodash version is reachable in production code paths."

Prior findings

finding_variant — variant exploitation

Signal: Whenever a finding is verified, CodeWall analyses it and asks: "Is this the same bug on a different surface?"

Why it matters: Bug bounties, manual pentests, and even your own internal review usually catch the first instance of a vulnerability. The second, third, and fourth instances on adjacent endpoints — same auth model, same parameter handling, same parser — almost always exist and almost always go untested.

Trigger: Automatic, on every finding that reaches confirmed status.

Typical hunt:

Parent finding: IDOR on /api/orders/{id}. Authorisation check is missing on order lookup.

Variant proposal: Test sibling endpoints under the same auth model — /api/users/{id}, /api/invoices/{id}, /api/documents/{id} — for the same missing check.

The variant generator deliberately avoids:

  • Re-running the same test on the same surface (verification, not exploration)
  • Targets already covered by the parent's class-scope (e.g. if the parent says "all POST endpoints accept unauthenticated calls", it won't propose another POST endpoint variant)
  • Generic "OWASP top 10" advice unrelated to the actual finding

If the parent's evidence is broad enough that no genuine variants exist, the system produces zero proposals rather than padding the queue.

Asset analysis

asset_context — tech-stack-driven hypotheses

Signal: When a new asset is discovered or its tech narrative changes, the AI proposes hunts based on what it knows about that stack's typical weaknesses.

Why it matters: Some classes of vulnerability are configuration- or pattern-specific rather than CVE-specific — they don't get a CVE number but they're still real (e.g. exposed .git directories, unauthenticated GraphQL introspection, dev endpoints leaking into production).

Trigger: Automatic when an asset's technology_narrative is generated or updated.

Typical hunt: "Asset api.example.com runs Hasura GraphQL based on the response signatures. Hunt: verify whether the introspection endpoint and the admin secret header are exposed."

llm_review — daily AI review pass

Signal: Once per day, an AI agent reviews your full attack surface — assets, prior findings, recent changes — and proposes hunts on areas it considers under-tested or particularly interesting.

Why it matters: Catches gaps that none of the other signals would surface. The reviewer has full context — it knows what's already been confirmed, what's been dismissed, and what's never been touched.

Trigger: Daily at the time configured in your hunting settings (default: enabled).

Typical hunt: "Recent recon discovered three subdomains under *.staging.example.com, none of which have been tested in any prior run. Hunt: a focused recon + auth-test pass on the staging subdomain group."

How CodeWall picks what reaches your queue

For all CTI sources, every advisory is evaluated against your specific tech stack before becoming a hunt. The matcher considers:

  • Direct vendor/product matches between the CVE's CPE strings and your asset technologies
  • Transitive matches (framework bundles affected component, BaaS ships affected internal component)
  • Crown-jewel asset weighting (a CVE on a critical asset gets prioritised over the same CVE on a low-value asset)

For variant and asset hunts, the AI generator is constrained to:

  • Only produce hypotheses that name specific endpoints, parameters, or surfaces
  • Only target assets it has actually seen in your inventory (no hallucinated targets)
  • Cap severity at the parent finding's severity for variants (no scoring escalation)

The result: if a hunt reaches your queue, it has a real reason to be there. You don't need to filter through CVE noise.

On this page