Consider a new way to think about testing for vulnerabilities. Security Testing Strategy
Background:
From the research and recommendations proposed here: gitlab-design#479 (closed) it's come to light that we don't have a strategic approach to when security tests run and what they should be scanning. Today we have scans running on the full repository which might take too long to complete and thus are left out of the pipeline. DAST is a good example of this.
Idea
Assess a 2 phased security testing and scanning approach that benefits both the developers and security engineers.
What this might look like.
There are 2 phases or types of security testing to consider:
- Incremental and targeted testing
- Comprehensive testing
Incrimental Testing
During the development phase, we should be scanning only the changes that are being made by developers and we should be scanning earlier in the process than we are today. Doing so will reduce the chances of a security engineer having to do code reviews when high-risk vulnerabilities are detected.
Pre-commit
We should consider adding SAST, secret detection into the Web IDE to run pre-commit. This will allow the developer to resolve or even flag vulnerabilities detected in their changes before they commit them. This way we are reducing the number of vulnerabilities and secrets that need to be addressed before merging, thus leading to a quicker review process and any other benefits resulting from having fewer vulnerabilities to handle in the MR.
Post-commit
Security scans should only be running on the changes (and their dependents) in the feature_branch. Showing all the vulnerabilities detected both within changes and outside of the changes will only serve to overload the user and result in a merging of the vulnerabilities into master. Showing all vulnerabilities from source and commit serve no one any benefit. Existing source_branch vulnerabilities should be handled by the security team outside of the MR. See Comprehensive Testing below.
Pre-release
In staging and deployment, we should run targeted dynamic tests. This will reduce the time to complete the scan and ensure the scans are actually run instead of being bypassed because they take too long. Full dynamic and static testing should be run on regularly scheduled pipelines where they can be started over-night or at a time when it is convenient for the customer.
Comprehensive Testing
The security team should be running comprehensive tests of the project from the security dashboard. This is where time-consuming and technically expensive testing should occur. Test results should be populated in the dashboard after the tests have completed, and the security engineers can being resolving vulnerabilities right from there.