Repository navigation
v1.7.1
TODO When updating
- Run
composer recipes:install smartbooster/standard-bundle --reset --forceto pick up the updatedmake/security.mk,
dast_scan/build-plan.shanddast_scan/scripts/(the set of copied files is unchanged, so there is no new dotted manifest) - The DAST scans now fail the build as soon as an alert reaches
failOnRisk(defaultLow), where they used to always exit0:
before enablingdast-blackbox-cion a project that already ran it, either arbitrate the current alerts indast_scan/alert-filters.json
or raisefailOnRiskin the project'sdast_scan/targets.json; see docs/security.md - Widen
reportRisksindast_scan/targets.jsonto at least the levels covered byfailOnRisk(["info", "low", "medium", "high"]with
the default), otherwise the CI fails on alerts absent from the reports - The first run of each
dast-*target now downloads theascanrulesBetaadd-on into the container (setDAST_ADDONS=to opt out)
Fixed
All the following is added content but it aim to fix the overall behavior of zap scan tool chain.
dast_scan/build-plan.sh:exitStatusjob appended to every generated plan, the gate that turns an alert into a red pipeline
(ZAP itself always exits0).errorLevelcomes from the newfailOnRiskkey oftargets.json(defaultLow),warnLevelis
Informational, andalwaysRun: truekeeps the status set when an earlier job interrupts the plandast_scan/build-plan.sh: optionaldast_scan/alert-filters.jsonbaseline, rendered as analertFilterjob emitted before any
traffic-generating job (a filter only applies to the alerts raised after it is registered). An alert requalified asFalse Positive
is skipped byexitStatuswhile staying visible in the report ; the non-ZAPnotekey of each filter is rendered as a YAML comment
above the filter it documents, so the generated plan carries the arbitration. Liketargets.json, the file is project-specific and
never shipped by the recipe- Three custom passive scan rules in
dast_scan/scripts/, covering vulnerabilities Qualys reports and ZAP has no native equivalent for :form-autocomplete.js(id9000001, QID 150112) :type="password"input with autocompletion disabled neither on the field nor on
its form — ZAP retired its own rule10012in 2018, Qualys still reports itblank-target-links.js(id9000002, QID 150222) : cross-domaintarget="_blank"link withoutrel="noopener"— the native rule
10108only alerts whenrelexplicitly containsopener, so a link with norelat all never triggers it, at any thresholdclient-side-cookies.js(id9000003, QID 150122/150123) : cookie written by the served JavaScript — it never appears in a
Set-Cookieheader, so the native rules10010/10011are structurally blind to it
make/security.mk:DAST_ADDONSvariable (defaultascanrulesBeta), installing the listed add-ons into the container before the scan.
The official image ships the release add-ons only, and the CORS active scan rule (alert40040, equivalent of Qualys' QID 150631) lives
in beta. The install is a separatezap.shinvocation in the same container : doing it in the-autorunrun pulls a newer
commonliband breaks the custom scripts (Could not initialize class ...ScanRuleMetadata)make/security.mk: ZAP'szap.logcopied out of the container intodast_scan/report/<target>.logbefore--rmdiscards it. In
-cmdmode the log never reaches stdout, so it is the only way to read the warnings counted by the report'sinsight.log.warn; the
copy is unconditional and the exit code saved beforehand, so a failing scan still yields itdocs/security.md: "The gate (failOnRisk)", "The baseline (dast_scan/alert-filters.json)" (schema, theString.matches()whole-URL
trap, the silence of a filter matching nothing) and "Add-ons (DAST_ADDONS)" sections ; the custom rules section now lists the four
shipped rules and reserves the9000001+id range for home-made ones
Changed
dast_scan/scripts/phpinfo.js: id100001→9000004, to sit in the9000001+range now reserved for the bundle's own scan rules
Contributed by @mathieu-ducrot