StackHawk Integration with DefectDojo
StackHawk Integration with DefectDojo
StackHawk is a commercial dynamic application security testing (DAST) platform built for developers. Its scanner, HawkScan, is built on the open source ZAP engine and runs from the hawk CLI or a Docker image in local and CI environments, driven by a stackhawk.yml configuration file. It tests running web applications and APIs, including REST, GraphQL, SOAP, and gRPC services, and sends results to the StackHawk platform. DefectDojo imports the JSON payload of StackHawk's scan-completed webhook event.
StackHawk Integration with DefectDojo
Our developers like StackHawk because HawkScan runs in the same pipeline as their tests and gives them results before a merge. Our security team needs those results in the same place as SAST, SCA, and pentest findings, with SLAs and reporting across every application. Importing StackHawk webhook events into DefectDojo gives us both. Each HawkScan run updates a Test for that application and environment, findings carry the paths where they were seen, and triage decisions made in StackHawk come across with them.
Why StackHawk Matters
Some vulnerabilities only show up when the application is running and answering requests. DAST covers that ground.
- HawkScan tests the running application, so it sees issues in headers, authentication, session handling, and responses that static tools can't.
- It is designed for CI, so scans can run on every pull request instead of quarterly.
- It understands API specifications such as OpenAPI and GraphQL schemas, which helps it reach endpoints a crawler would miss.
- Findings link back to the request and response in StackHawk, along with a cURL command for reproducing them.
- Per-scan results show what one build looks like. They don't show how long an issue has been open across releases or how it compares with other applications.
Advantages of This Integration
What we gained by sending StackHawk results through DefectDojo:
- Deduplication by plugin, application, and environment. DefectDojo hashes StackHawk findings on the plugin ID, application name, and environment, so each check in each environment is tracked once across scans.
- Triage carries over. If every path of a finding is marked Risk Accepted or False Positive in StackHawk, the DefectDojo finding arrives with the same status.
- Lifecycle through reimport. Each new webhook payload reimported into the same Test closes findings that HawkScan no longer reports and reopens ones that come back.
- Endpoints for every path. Every affected path becomes an endpoint on the finding, so a single misconfiguration on 20 routes is one finding with 20 locations.
- Cross-tool reporting. DAST results sit on the same Asset as code and dependency findings, with SLAs and Jira push applied the same way.
How This Integration Works
DefectDojo imports StackHawk data with the StackHawk HawkScan scan type. The input is the JSON body of StackHawk's scan-completed webhook event, not a file exported from the HawkScan CLI.
1. Capture the webhook payload. Enable StackHawk's webhook integration (check that your StackHawk plan includes it) and point it at a small service you host. StackHawk's own DefectDojo guide recommends saving each payload as-is to a file and then uploading it. The parser checks that the file has "service": "StackHawk" and a scanCompleted object, and rejects anything else.
2. Import it. Your webhook receiver can call the DefectDojo API, which works in Community Edition and DefectDojo Pro:
curl "https://YOUR_INSTANCE/api/v2/import-scan/" \
-H "Authorization: Token $DD_API_TOKEN" \
-F "scan_type=StackHawk HawkScan" \
-F "file=@stackhawk-webhook.json" \
-F "product_name=storefront-api" \
-F "engagement_name=DAST" \
-F "auto_create_context=true"
DefectDojo Pro users can call Universal Importer from the same receiver or a pipeline step:
universal-importer import \
--defectdojo-url "https://YOUR_INSTANCE.cloud.defectdojo.com/" \
--scan-type "StackHawk HawkScan" \
--report-path "./stackhawk-webhook.json" \
--product-name "storefront-api" \
--engagement-name "DAST" \
--auto-create-context
For occasional manual imports, upload a saved payload in the UI with Import Scan Results and the StackHawk HawkScan scan type.
3. Reimport for later scans. After the first import, send each new payload for that application and environment to /api/v2/reimport-scan/ so the Test reflects the latest scan.
Data Granularity: What Gets Imported
| DefectDojo Field | Source in StackHawk Payload | Notes |
|---|---|---|
| Title | pluginName |
The HawkScan check name |
| Severity | severity |
Used as StackHawk reports it (High, Medium, Low) |
| Description | findingURL |
Link to the finding in the StackHawk platform |
| Steps to Reproduce | paths |
Each path with its status and a link to the request and cURL |
| Endpoints | host plus each path |
One endpoint per affected path |
| Vuln ID from Tool | pluginId |
The scanner plugin identifier |
| Component Name | scan.application |
Application name |
| Component Version | scan.env |
Environment name, for example Development |
| Service | scan.application |
Also set to the application name |
| Date | scan.startedTimestamp |
Scan start time |
| Occurrences | totalCount |
Number of paths where the issue was found |
| False Positive / Risk Accepted | Path status |
Set only when every path has that status |
| Finding type | Dynamic | All findings are marked dynamic |
| Deduplication | Hashcode | Vuln ID from tool, component name, component version |
Within one payload, findings are keyed on plugin ID, so each check appears once. The Test description is set to a link to the scan in StackHawk.
Use Cases
Pull request scanning: HawkScan runs against an ephemeral environment on every pull request. The webhook receiver reimports into a Test for that application's Development environment, so developers see new issues in StackHawk while the security team tracks the same findings in DefectDojo.
Separating environments: Because the environment name is stored as the component version and is part of the hashcode, a finding in Staging and the same finding in Production are tracked separately. Teams can apply stricter SLAs to production while still seeing pre-production results.
API security programs: Teams scanning many APIs from OpenAPI specs import every application into its own Asset. Security leads get one view of open DAST findings by severity and age across the API portfolio.
Release reviews: Before a release, an AppSec lead filters the Asset for open High findings across DAST and SAST and confirms anything left open has an approved risk acceptance.
Operational Tips
- Import one application and environment per Test. Mixing environments in one Test makes reimport close findings that are still open elsewhere.
- Keep application and environment names stable in StackHawk. They feed the hashcode, so renaming either creates a new set of findings in DefectDojo.
- Do triage in one place where you can. Statuses come across from StackHawk only when every path shares the same status, so mixed triage on a finding stays active in DefectDojo.
- Save payloads before uploading, as StackHawk recommends. A stored copy lets you replay an import if your receiver or DefectDojo is unavailable.
- Use
minimum_severityif your pipeline runs many Low checks you don't intend to track. - Configure HawkScan authentication properly. Unauthenticated scans tend to return mostly header findings, and DefectDojo can only track what the scanner reached.