What we still need to verify : 2 points in this profile are not yet confirmed against vendor documentation.
- Current integration list: confirm against vendor documentation
- Specification formats accepted for API scanning: verify
Treat these points as unconfirmed. They are open items in the catalog's verification queue, and this note stays until each is checked against the vendor's documentation.
What it does
StackHawk inverts the usual DAST operating model. Instead of a console where a security team schedules scans against deployed applications, the scanner is a containerized CLI and the configuration is a YAML file living in the application repository next to the code. A developer sets the target host, authentication method and scan policy in that file, starts the application in the pipeline, and runs the scanner against it. Results upload to a hosted console for history and triage, but the scan is a build step the team owns.
Under the covers the engine is built on the open source ZAP scanner, so the underlying attack checks and proxy-based approach are familiar and inspectable. What StackHawk adds is the parts that make ZAP awkward in CI: opinionated configuration, first-class handling of API definitions so REST, GraphQL and SOAP endpoints are enumerated from a specification rather than crawled, authentication helpers for token and cookie based flows, and result deduplication across runs so the pipeline fails on new findings instead of the same backlog every time.
Where it fits
This runs in the build pipeline against an ephemeral or pre-production instance of the application, which is the point. Because the target is a throwaway environment, the scanner can submit forms and send real attack payloads without the caution production scanning demands. Developers own the configuration file and see the failure in their own pull request. For it to work the application must be startable in CI with seeded data and test credentials, which is the real prerequisite and the main adoption hurdle.
Strengths
- Configuration as code keeps scan scope in sync with the application as it changes, instead of drifting in a central console.
- Specification-driven API scanning covers endpoints no crawler would find, which matters for backend services with no UI.
- Running against ephemeral environments removes the production safety constraints that limit what a scanner may do.
- Building on an open engine keeps check behavior inspectable.
Limitations
- It depends on your ability to stand up a working application with data and credentials inside CI. Teams that cannot do this get little value.
- Detection depth inherits the limits of the underlying engine: injection, cross-site scripting and misconfiguration, not authorization or business logic.
- Pre-production focus means it says nothing about the configuration of what is actually running in production.
Who it suits
Well matched to engineering organizations with mature CI, containerized applications and a culture where developers accept security checks in their own pipeline. A poor fit for teams with legacy applications that cannot run outside a hand-built environment, or for a security group that wants to scan the estate from a central console without developer involvement.
Used StackHawk? Recommend it under your own name and title.
Recommend this tool