DAST: Add a config option for defining which rules to execute
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_RULESbefore updating to the new release. Not doing so would break the DAST job. Updating
DAST_EXCLUDE_RULESis 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_RULEScan 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.
- 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
Implement an option (e.g.
DAST_ONLY_INCLUDE_RULES) that allows specifying which rules to execute.
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.
zapv2.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 if the rules are still executing
zapv2.pscan.disable_all_scanners, and the corresponding
Update the docs with instructions on using
DAST_ONLY_INCLUDE_RULES. Mention that it takes precedence over