DAST: Add a config option for defining which rules to execute
Release notes
TBD
Problem to solve
When testing large applications we found that it's crucial to have tight control over which DAST rules are executed. I wrote about this in more detail in a blog post.
DAST provides the config option DAST_EXCLUDE_RULES
that can be used to define which rules NOT to executed. While this gives some control over the executed rules, it has some shortcomings:
- New DAST releases might ship with new rules, which makes it necessary to manually add these rules to
DAST_EXCLUDE_RULES
before updating to the new release. Not doing so would break the DAST job. UpdatingDAST_EXCLUDE_RULES
is tedious because there is no simple way to see which rules were added. In consequence, users might pin DAST to a specific version and rarely update. - DAST configs that use
DAST_EXCLUDE_RULES
can get unwieldy, which leads to less readable and harder to maintain configs. This is in particular the case if DAST rules are split up across several jobs. In such a scenario, the problem is that the rules that should not be executed need to repeated in every job definition and it becomes unclear which rules a job acutally executes. See the example below:
# We assume for the sake of brevity DAST has only 9 rules with ids 1 to 9. These rules are split up into 3 jobs.
# In reality, DAST has many more rules and they might be split up in many more jobs (12 DAST jobs in our internal pipeline)
# making real configs even more difficult to read and maintain.
job1:
- variables
- DAST_EXCLUDE_RULES: "4,5,6,7,8,9" # executes rule 1,2,3
...
job2:
- variables
- DAST_EXCLUDE_RULES: "1,2,3,6,7,8,9" # executes rule 4,5
...
job3:
- variables
- DAST_EXCLUDE_RULES: "1,2,3,4,5" # executes 6,7,8,9
...
Our internal pipeline configuration got very unreadable so that we had to implement a helper function that allowed us to express which rules we want to run in a job, as opposed to which rules not to run https://gitlab.com/gitlab-org/gitlab/-/blob/master/.gitlab/ci/dast.gitlab-ci.yml#L54. This greatly improved readability, but could not address 1).
It would be great if DAST provided an option to define which rules to execute, in addition to which rules NOT to execute.
Intended users
- Sasha (Software Developer)
- Devon (DevOps Engineer)
- Sam (Security Analyst)
- Simone (Software Engineer in Test)
User experience goal
The UX goal is twofold:
- Make it easy for users to update to new DAST releases that require tight control over which rules are executed.
- Increase the readability of DAST configs
Proposal
Implement an option (e.g. DAST_ONLY_INCLUDE_RULES
) that allows specifying which rules to execute.
If both DAST_EXCLUDE_RULES
and DAST_ONLY_INCLUDE_RULES
are configured for the same scan and have the same rule added to both, the included rules should take precedence and the rule executed.
Implementation plan
-
Reimplement DAST_EXCLUDE_RULES
usingzapv2.ascan.disable_scanners
andzapv2.pscan.disable_scanners
. Ensure that the rules are not executing. @avielle tested the functionality and it appears as if the rules are not executing, but ensure that this is the case. Go back to workflowsolution validation if the rules are still executing -
Implement DAST_ONLY_INCLUDE_RULES
usingzapv2.ascan.disable_all_scanners
,zapv2.pscan.disable_all_scanners
, and the correspondingenable_scanners
rules -
Update the docs with instructions on using DAST_ONLY_INCLUDE_RULES
. Mention that it takes precedence overDAST_EXCLUDE_RULES
cc @gitlab-org/secure/dynamic-analysis-be