Skip to content

GitLab Next

GitLab
GitLab
Closed
Opened by Fabio Busatto@bikebillyContributor2 of 3 tasks completed2/3 tasks

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.

What is the type of buyer?

GitLab Ultimate

Links / references

/label feature

Edited by Avielle Wolfe