> 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

## 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

Bug Hunts run automatically once your external scope is configured — there is nothing to schedule by hand. 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** (default, production-safe) — the minimal set of discovery and enumeration tooling. Conservative, read-only reconnaissance.
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.

Nullify paces its requests conservatively and backs off when a target shows signs of stress, so hunts stay safe to run against production. For full exploit-chain validation with reproduction evidence, use [Pentests](/capabilities/pentests.md).

## 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. Bug Hunts surface and prioritize exposure through reconnaissance; for active exploitation with validated proof, promote a discovered application to a [Pentest](/capabilities/pentests.md).

## 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.