fix(ci): stop DAST workflow reporting red on a passing ZAP scan#34
Merged
Conversation
The scheduled DAST job was red even though ZAP reported FAIL-NEW: 0 / PASS: 65. Root cause: the `zaproxy/action-api-scan` step used `format: openapi` against `/api/v1/health`, which is not an OpenAPI document. With no API definition to import the step produced no report, and the action's hardcoded artifact upload then failed with "File report_md.md does not exist" — turning a genuinely passing scan red. `fail_action: true` is not a fix here: that action fails on *any* alert, including informational passive-scan WARNs (the scan legitimately had WARN-NEW: 2), which would also be a false red. Run zap-baseline.py directly with `-I` so warnings stay informational and the scan's own exit code is the single source of truth: the job is green on a clean/warn-only scan and red only on a genuine FAIL-level finding. The HTML/MD/JSON report is uploaded as an artifact by us.
|
Note Gemini is unable to generate a review for this pull request due to the file types involved not being currently supported. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Why
The scheduled DAST (OWASP ZAP) workflow shows red on the Actions tab even though ZAP genuinely passes:
Root cause: the
zaproxy/action-api-scan@v0.9.0step ran withformat: openapiagainsthttp://localhost:3001/api/v1/health. That endpoint is not an OpenAPI document — the app exposes no OpenAPI/Swagger spec at all — so ZAP had nothing to import, produced no report, and the action's hardcoded artifact upload failed on the missingreport_md.md. A passing scan was rendered red by an infrastructure bug, not a finding.fail_action: trueis not the fix: per the action's own docs it fails the build on any alert, including the informational passive-scan WARNs this scan legitimately has (WARN-NEW: 2) — that would just be a different false red.What
zap-baseline.pyinvocation using-I(do not fail on warnings). The scan's own exit code is now the single source of truth:zap-baseline-reportartifact by an explicitupload-artifactstep (always runs), so report-file naming can never fail the job again.Verification
dast-zap.ymlvalidated as well-formed YAML.workflow_dispatchon this branch; the run is green with the ZAP report attached as an artifact (linked in the final report).