StackHawk Features: What HawkScan Covers in 2026

StackHawk is a developer-oriented dynamic application security testing platform. HawkScan attacks a reachable application, while the platform stores results and connects scans to engineering workflows.

As of July 31, 2026, StackHawk documents runtime tests for web applications and APIs, including protected routes and authorization boundaries. Its newer test surfaces cover LLM applications and remote MCP interfaces.

Teams can run those tests in delivery pipelines or through hosted scans. StackHawk also provides agent-driven remediation workflows.

HawkScan does not replace the code-layer checks bundled in CodeAnt’s code security platform. Choose StackHawk for repeatable runtime testing inside delivery pipelines, or evaluate broader SAST-versus-DAST coverage when one control plane must also cover code analysis.

TL;DR

StackHawk features at a glance

StackHawk has two operational parts. HawkScan performs the scan, while the StackHawk Platform organizes applications and their results.

The platform also manages scan policies and users. Integrations connect those resources to engineering workflows.

The scanner can execute beside an internal application without exposing that target to a vendor-hosted scanner. Teams that prefer managed execution can use the Hosted Scanner; teams evaluating a mixed toolchain can compare these layers with the jobs covered by SAST and DAST tools.

This is runtime coverage. The OWASP Web Security Testing Guide is a useful reference for the wider testing surface, while the OWASP Application Security Verification Standard helps teams translate security requirements into verifiable controls.

What features does StackHawk actually include?

HawkScan runtime testing and configuration as code

HawkScan needs a reachable running target. It connects over HTTP(S) and probes crawled or imported routes for vulnerabilities.

The public documentation listed HawkScan 6.2.0 on July 31, 2026. The scan engine is available through a native hawk CLI or a Docker image.

A minimal stackhawk.yml identifies the StackHawk application and its environment. It also specifies the host that HawkScan will test.

``yaml app: applicationId: your-application-id env: Development host: http://localhost:8080 ``

The same file defines authentication and scan scope. It can supply API schemas and their input values while applying the selected redaction and scan policy.

Teams can commit the file beside the application or layer additional configuration at run time. Hosted Configuration moves YAML into the platform, while hawk:// references let a scan consume platform-managed configuration or OpenAPI material.

Configuration as code makes targets and exclusions reviewable changes, but it does not prove coverage. During a pilot, record discovered and protected routes with an automated pentesting checklist, then compare that inventory with the expected attack surface.

Route discovery and API schema support

For REST APIs, HawkScan can read OpenAPI v2 or v3 from a path on the target or from local files. The schema can instead be supplied as inline YAML or stored on the StackHawk Platform.

It uses the schema to seed routes and construct inputs. Custom values and Faker formats replace placeholder data that could miss valid code paths.

GraphQL scans can use introspection or a schema file. SOAP accepts a WSDL, while gRPC uses reflection or protobuf descriptor sets.

The broader configuration reference also includes JSON-RPC. For a remote MCP server, HawkScan completes the protocol handshake and retrieves the available tools.

It derives test inputs from each tool schema. A resulting finding identifies the affected tool and parameter.

The OWASP API Security Top 10 provides a neutral vocabulary for common API risks. StackHawk’s separate API Discovery feature connects to source repositories and generates OpenAPI specifications with sensitive-data or activity context.

The official docs mark API Discovery as Enterprise-only. Buyers should distinguish scanner schema ingestion from source-derived inventory and document each discovery method in their vulnerability-scanning tool inventory.

*StackHawk’s official API Discovery documentation shows the repository inventory that feeds its source-derived attack-surface view. The screenshot is from StackHawk’s public documentation, captured July 31, 2026.*

Authenticated scanning and business-logic tests

Authenticated scans can sign in with form credentials or selected OAuth flows. A pipeline can instead inject a cookie or token, and HawkScan can send cookie or bearer authorization on later requests.

Custom JavaScript or Kotlin scripts handle authentication flows that the built-in options cannot express.

A configuration also needs a protected test path plus logged-in and logged-out indicators. HawkScan uses those checks to confirm the initial login and detect a lost session during the scan.

If a scanner falls back to a login page, a green run can hide untested routes. Use controlled test users and verify the route count.

Store credentials in the CI secret store. Record these assumptions with your automated pentesting evaluation questions.

StackHawk’s business-logic feature adds plugins for BOLA and BOPLA checks. Separate plugins cover BFLA and multi-user tenancy checks.

Custom HawkScan Testing Engine scripts can model workflows and user roles. They can also reproduce state changes or domain rules that a generic crawler cannot infer.

The official docs require additional configuration for this context. An IDOR vulnerability needs objects and identities with different access boundaries.

Scan policies and production-safe mode

Active DAST sends attack payloads and may modify data. Full scans therefore belong on authorized targets where test data and side effects are acceptable.

The OWASP Top 10 supplies a risk taxonomy, but policy selection must reflect the target’s business operations. StackHawk’s DEFAULT_PASSIVE_ONLY policy sends standard HTTP requests without active attack behavior.

The passive policy examines headers and cookies without sending attack payloads. It checks information disclosure alongside TLS and other configuration issues.

It cannot provide the same evidence as an active attack policy. For continuous versus annual pentesting, record the permitted scan depth and target environment for each cadence.

The test plan should also name the authorization boundary and recovery procedure.

If the scan supports an audit, map its scope and evidence to the relevant compliance penetration-testing requirement. A passive DAST result is not interchangeable with active test evidence.

LLM and remote MCP server testing

StackHawk’s LLM testing documentation maps its checks to the OWASP Top 10 for LLM applications. The documented checks cover prompt injection and sensitive-data disclosure, followed by improper output handling.

The same feature set tests for system-prompt leakage and unbounded consumption.

Teams enable the relevant plugins in a scan policy so these checks run with the DAST workflow.

Remote MCP testing connects to a Streamable HTTP endpoint and initializes a session. HawkScan discovers the server’s tools and generates calls from their input schemas.

It checks the responses for injection and disclosure behavior. Findings identify controls that the test did not observe.

HawkScan does not infer private business rules from a tool schema. Authorization and stateful workflows still require test identities and custom logic.

These tests cover AI-facing HTTP surfaces, not the provenance of model-training data or software dependencies. They also do not trace data flow through source code.

CISA’s Secure by Design guidance frames runtime testing as one product-security control.

Local, hosted, CI/CD, and agent-driven execution

HawkScan can run on a developer workstation or in Docker. Teams can install it on a server or run it in Kubernetes.

A CI/CD job can invoke the same scanner in a delivery pipeline.

The documented pipeline integrations include GitHub Actions and GitLab CI/CD. StackHawk provides additional setup paths for Jenkins and Azure Pipelines, with a separate path for CircleCI.

A configurable severity threshold can fail a scan, while GitHub Code Scanning can surface qualifying alerts. Start with a deterministic target, then expand route discovery and authentication after the job is stable.

As with integrating SAST into CI/CD, assign an owner and exception process to each blocking gate. A pilot should also define how the runtime job interacts with other automated pentesting tools for DevSecOps.

StackHawk also offers cloud-hosted scans and agent skills. A supported coding agent can configure HawkScan and run it, then use the findings to prepare a patch.

The agent can interpret the result and rescan the changed application. The official docs say this AI-powered workflow requires an active Secure or Scale subscription, with Wingman listed as another qualifying plan.

Buyers should verify plan packaging and require appropriate review before an agent edits security-sensitive code.

Finding evidence, validation, triage, and reports

The platform groups results first by application and environment. Within that scope, teams can navigate by scan or path and filter by severity or triage state.

A finding retains the HTTP request and response along with its references and confidence. It identifies affected methods and paths, while the Validate action generates a curl command for reproduction.

A developer can run the generated request while stepping through code.

*The public StackHawk scans documentation uses this screen to explain paths and severity. It also shows the triage state; the image is first-party documentation evidence captured July 31, 2026.*

Teams can mark a finding as Assigned or Risk Accepted. False Positive provides the third state, while comments and ticket links preserve the reasoning or follow-up work beside it.

An audit package needs testing scope and disposition history, not only totals. Compare the export fields with an audit-oriented penetration-test report before using them as assessor evidence.

*StackHawk’s public documentation shows the Validate action generating a curl command from the recorded request. The example contains redacted credentials and a localhost target; captured July 31, 2026.*

Severity is one prioritization input, not the complete queue. For known CVEs, the CodeAnt vulnerability database provides record context, while EPSS-based prioritization adds the probability signal defined by FIRST’s Exploit Prediction Scoring System.

Asset sensitivity and reachability help determine whether a finding belongs near the top of the queue. Compensating controls and reproduced impact then refine that decision.

Workflow integrations and enterprise controls

The GitHub integration associates scans with commits and can add summaries to pull requests. Slack sends scan completion or failure notifications, while Jira can create or link issues subject to plan support.

StackHawk also documents Microsoft Teams and other workflow connections. At the program layer, the platform manages applications and environments alongside teams and their roles.

Administrators can centralize scan policies and reports. Hosted configuration keeps configuration and user secrets in the platform.

SSO and five Enterprise roles supply the access-control layer for larger deployments.

Those documented roles are Owner and Admin at the broadest scope, followed by Team Admin. Member and View Only provide narrower access.

REST API access and Jira support depend on the appropriate plan or support enablement. Organization IP allow lists and some security settings carry the same qualification.

Confirm these items during procurement instead of assuming they are base features.

When several scanners feed one queue, define aggregation and ownership with the model described in this ASPM guide.

What StackHawk’s feature set does well

YAML captures scan intent, while local or CI execution can keep an internal pre-production service private. Schema-aware inputs improve API route coverage.

Authentication checks reduce the risk of scanning only public pages. Curl recreation gives developers a request they can reproduce.

Pull-request summaries and severity gates bring scan results into code review. Jira links and Slack notifications carry the work into issue tracking and team communication.

Triage history records each disposition, while targeted rescans test the affected route after a change.

NIST’s Secure Software Development Framework calls for security practices throughout development. Runtime tests in CI contribute evidence when teams preserve the test record and its dispositions.

StackHawk limitations and missing security layers

HawkScan observes a running target, so it does not replace static application security testing for source and data-flow analysis. Software composition analysis remains responsible for vulnerable packages and licenses.

Secret scanning finds exposed credentials in repository content. Infrastructure-as-code scanning examines deployment definitions before the infrastructure is provisioned.

Runtime requests also do not inspect cloud infrastructure security across the network and identity layers. Storage and control-plane exposure need infrastructure-specific controls.

HawkScan needs complete schemas and valid test data to exercise API operations. Working authentication and accurate route exclusions determine which protected paths it reaches.

The target services must remain stable while the test runs. Teams should account for WAF behavior and isolate endpoints whose destructive effects cannot be safely reversed.

The official gRPC documentation states that the protocol does not support TLS/authentication as of July 31, 2026. Test that limitation in a protocol-specific proof of concept instead of extrapolating from REST support.

DAST does not equal a complete penetration test. Custom scripts can model selected workflows, but they do not independently discover novel attack chains or perform an architecture review.

Social engineering also sits outside the scanner’s runtime requests. Human-led hypothesis building must be scoped separately.

Review automated pentesting mistakes to avoid before treating a clean run as evidence of absence.

StackHawk vs CodeAnt AI features by use case

This is a scope comparison based on public documentation, not a hands-on detection benchmark.

StackHawk fits teams that already have code-layer controls and need configurable runtime DAST/API testing in CI. CodeAnt fits teams that want repository analysis alongside dependency and secret scanning.

Its scope also includes IaC analysis and prioritization, with pentesting available in the same platform. A layered program can use both after assigning ownership for duplicate findings and defining how gates handle exceptions.

Who should choose StackHawk?

StackHawk is a practical choice when all of these operating conditions are true:

• a running pre-production app or API is available inside the build environment;

• developers will maintain scanner configuration and test identities;

• runtime findings need request/response evidence and quick reproduction;

• findings must reach the delivery and issue-tracking workflow; and

• the team already owns the missing code-security layers.

If the application cannot run reliably in CI, fix that execution path before making runtime DAST a blocking control. Missing authenticated test data creates a similar coverage problem, while an immediate code-analysis gap calls for a code-layer scanner first.

Define those prerequisites in your continuous pentesting requirements, then compare the operational choices in a review of continuous pentest tools for CI/CD. Pilot one representative service with controlled data and a rollback path.