Enable full scan for DAST
Problem to solve
Right now DAST is relying on Passive Scan by ZAP. This is safe as it doesn't perform any real attack, but it can spot only a portion of the possible vulnerabilities.
ZAP has also Active Scan that performs several additional checks. We can make the behavior available when a specific environment variable is set, without changing anything in the job definition.
- The active scan may take a long time to finish, and so it should not be the default option.
- The active scan is performed as a part of the full scan by ZAP. So, there's a consensus over changing the term from "active scan for DAST" to "full scan for DAST".
Implement Full Scan for ZAP to support additional DAST checks in Auto DevOps.
If the environment variable
DAST_FULL_SCAN_ENABLED is set, the tool will be executed with a different set of options to enable Full Scan against the given target.
This will be supported out of the box, and it will not require any change in the job configuration. This option will be available for the vendored default DAST template, and for Auto DevOps.
Metrics should be collected as described in the next section.
What does success look like, and how can we measure that?
Number of pipelines executed with the
Links / references
Modify the Python wrapper script to accept the boolean command line argument(see next)
--enable-active-scan; if set it passes the same set of arguments down to the
zap-baseline.py(they accept identical sets of arguments)
zap-full-scan.pyto DAST Docker image
Add shell code to the script in
DAST.gitlab-ci.ymlvendored template that sets
DAST_ACTIVE_SCAN_ENABLEDis set; not sure if we need to support ENV var checking in the DAST tool itself
Add tests and expectations for Active Scan for
- Update the README for DAST
[ ] Add Usage Ping for number of pipelines executed witha follow-up issue added
- Add documentation to EE on new DAST env var with description
- Auxiliary: add notes on using ENV vars vs command line flags to standardization notes for security products: ENV vars must be used by tools only in cases when underlying CLI tool does not provide a command line flag for it; ENV vars is the preferred way to configure tools in GitLab CI YAML
--auth-first-pageparam from usage message and add a backward-compatibility comment on the implementation