DAST for the master branch
Problem to solve
In AutoDevOps today, we run DAST only on feature branches, since DAST can unintentionally damage an application's state, which is not desirable in a production environment.
Users cannot know the current status of the master
branch, and so they can only check the report from the latest feature branch. This is complex, not easy to do, and doesn't display results about what they are actually deploying to production and any interactions that may occur between features.
There is also no base DAST scan to compare against for merge requests. This means that developers reviewing DAST results cannot be sure if the MR introduces new security issues or if they already existed.
Proposal
As part of AutoDevOps, run DAST on the master
branch inside a dedicated review app. Do NOT run DAST against a deployed environment like production
or staging
that a user has configured.
-
Can this re-use the existing technical mechanisms we have today for review apps? Yes it can. This is already being done on feature branches, and on default branches named something other than master
.
Introduce a mechanism, such as an environment variable, to disable DAST on master
if the users wishes to do so. By default, DAST should be run on master
.
-
To lessen the pipeline speed impact, can this be done in parallel with other stages in AutoDevOps? Perhaps using the [DAG] capability from 12.2?(https://gitlab.com/gitlab-org/gitlab-ce/issues/47063#note_198167487) -
Are environment variables a reasonable suggestion here or would something else be better? They're a good suggestion. We can use .gitlab-ci.yml
's ability to exclude jobs based on an environment variable to implement this.
Use the master
branch DAST results as a basis for comparison in MRs to determine vulnerabilities newly introduced in that branch
Intended users
Persona: DevOps Engineer Persona: Security Analyst Persona: Development Team Lead Persona: Product Manager
Further details
Telemetry: Usage ping and Gitlab.com reporting should indicate if DAST was run on master
Documentation
Documentation will need to be updated to describe the fact that DAST will apply to the master
branch and be very clear about it being done in a review app.
Testing
- Tests should be done to confirm that DAST results on
master
match what is expected from a respective feature branch. - Tests should be done to confirm deployed environments are not affected and that review apps are properly used.
What does success look like, and how can we measure that?
We can measure success of DAST on master
with:
- Number of DAST scans done on master in 30 days. Target = 1000
- Percentage of repos using AutoDevOps that have DAST on
master
enabled 30 days after this feature is live. Target = 50%- This will confirm users get enough value to keep this capability enabled.
- Percentage of vulnerabilities created from DAST on
master
results, rather than from an MR, in the first 30 days. Target = 25%- This will confirm that DAST on
master
is providing valuable report results that either weren't visible or weren't noticed on the MR DAST results.
- This will confirm that DAST on
What is the type of buyer?
Links / references
/label feature