04 / Self-hosted scanning

Your infrastructure. Your operating responsibility.

Plan a self-hosted API scanner with controlled network access, restricted credentials, reproducible configuration, and protected assessment reports.

Own the workflow, not just the machine

Self-hosting means choosing where work runs and who operates it. It does not automatically establish privacy, safety, or complete security coverage. Document the runner, approved network paths, credential handling, update process, and report location.

Separate software, configuration, credentials, and artifacts. Each has a different lifecycle. A replaceable runner should not contain the only copy of the evidence, and a report archive should not become an unmaintained credential store.

Select an appropriate host

A Linux server, macOS workstation, or Windows environment can play different roles depending on the selected tool's supported runtime. Verify current architecture and platform requirements. On a Raspberry Pi, review processor support and resource needs before assuming a container or binary will run unchanged.

For a persistent runner, assign an owner and prevent overlapping jobs. For an ephemeral runner, document how it is recreated without a personal account or manual secret. In either case, restrict access to the approved environment rather than exposing an entire internal network.

Distinguish baseline and active modes

ZAP's baseline documentation describes a spider and passive scanning without active attacks. The spider still sends requests. Review the exact behavior, request budget, and excluded operations with the application owner. A baseline label does not mean offline or guaranteed non-disruptive.

Make the run reproducible

Record the application revision, tool version, selected profile, test identity role, and output directory. Validate connectivity and authentication before proceeding. Treat a failed preflight as an incomplete assessment rather than a security pass.

Keep the process exit status separate from the review decision. A filesystem failure and an authorization observation require different responses. Preserve enough operational information to explain what happened without retaining unnecessary sensitive response content.

Protect the evidence after the run

Store detailed results in a restricted location and create a separate sanitized summary. Identify the retention period and artifact owner. Check what leaves the host through update downloads, telemetry, remote storage, and optional model-provider calls.

Read the complete self-hosted CLI workflow, compare platform considerations, and use the scope checklist before a supervised first run.

Primary references

Read the documentation that matches your tool, framework, and deployment. These sources provide context; they do not establish coverage of your environment.