Dynamic application security testing (DAST) is a process of testing an application or software product in an operating state.
When application has been deployed and started, DAST connects to the published service via its standard web port and performs a scan of the entire application. It can enumerate pages and verify if well-known attack techniques, like cross-site scripts or SQL injections are possible.
DAST doesn't need to be very language specific, because the tool emulates a web client interacting with the application.
Our goal is to provide DAST as part of the standard development process. This means that DAST is executed every time a new commit is pushed to a branch. We also include DAST as part of Auto DevOps.
Since DAST requires a running application, we can provide results for feature branches leveraging Review Apps, temporary environments that run the modified version of the application.
DAST results can be consumed in the merge request, where only new vulnerabilities, introduced by the new code, are shown. A full report is available in the pipeline details page.
DAST results will also be part of the Security Dashboard, where Security Teams can check the security status.
We also want to ensure that the production environment is always secure, by running DAST on the deployed app even if there is no change in the code. This can be done using the Security Control Panel.
We want to make DAST suitable for multiple environments (including production), and run it with proper settings depending on the case, without slowing down the process.
The next MVC is to support different types of DAST scan: https://gitlab.com/gitlab-org/gitlab-ee/issues/8577.
We have the advantage to provide testing results before the app is deployed into the production environment, by using Review Apps. This means that we can provide DAST results for every single commit.
Anyway, we can provide support for custom flows and provide DAST results for the master branch in Auto DevOps to better align with other existing tools.
We want to engage analysts to make them aware of the security features already available in GitLab. Since this is a relatively new scope for us, we must aim at being included in the next researches.
We can get valuable feedback from analysts, and use it to drive our vision.
We can also make them able to easily compare our tool with other existing solutions by supporting the OWASP WebGoat project.
