> For the complete documentation index, see [llms.txt](https://docs.nullify.ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.nullify.ai/capabilities/bug-hunts.md).

# Bug Hunts

> **Maturity: GA** — Defined in the production stack configuration (`iac/stacks/prod/module-dast.tf`); scope enforcement is a fail-closed control (`dast_enable_scope_enforcement`, fail-safe on).

## Overview

Nullify continuously watches your external attack surface the way an offensive security engineer would — discovering internet-facing assets, fingerprinting the services running on them, and probing for exposures before an attacker finds them. Bug Hunts combine passive reconnaissance, active service discovery, and protocol-aware analysis, and they lean on everything Nullify already knows about your code, dependencies, and cloud to focus on what actually matters.

Unlike a one-off scan, a Bug Hunt is a standing watch: Nullify re-runs it on a cadence, compares each run against the last, and only surfaces what has **changed**.

## How Bug Hunts run

When Bug Hunts are enabled for your tenant and a valid scope and schedule are configured, hunts can run automatically. Nullify runs each hunt on a recurring cadence and paces itself to your program's budget: as the surface stays stable, it settles into a lighter rhythm; when new exposure appears, it tightens back up. You can also trigger a hunt — or a single reconnaissance suite — on demand at any time.

### Change-only findings

Every run is diffed against the previous one. Nullify surfaces findings that are **New** or **Reopened**, and stays quiet about assets that are **Unchanged** or have been **Resolved**. This keeps a Bug Hunt from re-alerting on the same known exposure run after run, so the findings you see are always the delta since you last looked.

Your triage decisions persist across every future run. When you allowlist an asset, archive a finding, override its severity, set a priority, or leave a note, that decision travels forward — a rescan won't undo it or re-raise something you've already judged.

## What Nullify looks for

### Reconnaissance

Nullify maps your attack surface from the outside in:

* **Subdomain discovery** — passive sources such as certificate-transparency logs and DNS records, plus active discovery with adaptive wordlists.
* **Service and port discovery** — low-noise scanning across discovered hosts to find exposed services.
* **Service fingerprinting** — technology-stack and version identification, banner analysis, and HTTP inspection.

### Exposure and misconfiguration checks

Across discovered services Nullify checks for subdomain takeover, exposed or sensitive files, missing or weak transport security and certificate issues, absent security headers, exposed admin or debug interfaces, and other common internet-facing weaknesses. It performs protocol-aware analysis for web, database, infrastructure, container-orchestration, and cloud service endpoints — testing authentication, reviewing configuration, and checking for known weaknesses and weak credentials.

### Context from the rest of Nullify

Bug Hunts are sharper because they draw on the rest of the platform:

* **Code review findings** highlight likely injection points and vulnerable patterns worth probing from the outside.
* **Dependency findings** identify exploitable CVEs on exposed services and inform which exposures matter most.
* **Cloud context** contributes topology, reachability, and code-to-cloud mapping so an exposure can be tied back to the application and blast radius it affects.

## Intensity levels

Intensity controls how much tooling Nullify brings to a hunt:

1. **Low** — a reduced discovery and enumeration toolset. This is not a guarantee of zero production impact.
2. **Medium** — most of the available tooling, for a deeper assessment.
3. **High** — the full toolset, including heavier, more aggressive techniques such as brute forcing.

Choose intensity deliberately: a manual scan falls back to the saved intensity, then `medium` if no valid value is available. Intensity is not a substitute for scope, rules of engagement, or authorization. Some suites send active probes and can affect a service; agree a suitable environment and testing window.

## Controls

You stay in control of scope and noise:

* **Scope** — define in-scope assets (domains, IP ranges, CIDR blocks) and exclude assets you don't own or don't want tested (third-party services, partner networks).
* **Per-suite toggles** — enable or disable individual reconnaissance and analysis suites.
* **Severity floors** — set a minimum severity per vulnerability class so low-value classes stay quiet.
* **Per-finding triage** — allowlist, archive, override severity, set priority, or annotate any finding; decisions persist across future runs.

Nullify only tests assets you are authorized to test. Before a hunt runs against a target, ownership must be proven, and out-of-scope targets (loopback, private-network, and cloud-metadata addresses) are rejected.

## Evidence

Bug Hunt findings come with the reconnaissance evidence behind them — the discovered services and versions, open ports, technology fingerprints, and the exposure detail — plus a prioritized path to remediation. Selected authenticated and backend suites can perform active testing too. Promote a discovered application to a [Pentest](/capabilities/pentests.md) for a dedicated engagement with its own configuration and reporting.

## Where findings go

Bug Hunt findings flow into the same places as the rest of Nullify's work: the dashboard, Jira and other ticketing with ownership mapping, Slack and Teams notifications for critical attack-surface changes, and [Security Program Management](/capabilities/program-management.md) for campaign-driven attack-surface reduction. Discovered applications can be promoted directly into [Pentest](/capabilities/pentests.md) targets.

## Configuration

Configure Bug Hunts during [Onboarding](/getting-started/getting-started.md):

* Define in-scope assets (domains, IP ranges, CIDR blocks).
* Specify excluded assets (third-party services, partner networks).
* Link bug bounty program data if you run one.
* Adjust intensity, per-suite toggles, and severity floors.

## Suites, ownership, and rules of engagement

The suite catalog includes DNS enumeration, port scanning, web fingerprinting, Nuclei checks, browser exploration, authenticated walks, SPA checks, malware scanning, and lightweight or full backend pentests. Availability and dispatch depend on your deployment, enabled suites, credentials, and scope. A catalog entry does not mean every hunt runs it.

Before execution, review allowed and excluded targets, permitted techniques, rate limits, time windows, and the current rules-of-engagement version. Ownership proofs can use DNS TXT, an HTTP file, a meta tag, or a supported program-managed verification path. Confirm the specific proof and scope accepted for your tenant; redirects and resolved destinations remain subject to scope enforcement.

Importing a public HackerOne or Bugcrowd program produces a preview of scope and rules. Review the result and explicitly save it: import alone does not authorize testing or update your configuration. Third-party assets mentioned by a program are not automatically authorized.

The [Bug Hunts API](/api-reference/api-reference/bug-hunts.md) covers config, scans, suite runs, program imports, findings, and promotions. The suite-run history endpoint currently returns an empty list, so use scan history for execution evidence rather than treating an empty suite history as proof that nothing ran.