Merge request approval security policies should account for security scan logic when failing closed
Merge request approval security policies should account for security scan logic when failing closed
Release notes
Problem to solve
GitLab scanners have built in logic to determine when a scan should run. For example, dependency scanning checks to see if a .lock
file exists using the rule below:
.gemnasium-shared-rule:
exists:
- '**/Gemfile.lock'
- '**/composer.lock'
- '**/gems.locked'
- '**/go.sum'
- '**/npm-shrinkwrap.json'
- '**/package-lock.json'
- '**/yarn.lock'
- '**/pnpm-lock.yaml'
- '**/packages.lock.json'
- '**/conan.lock'
A project may have proper configuration of their scanners, but no .lock
file exists, and thus they are out of scope of dependency scanning enforcement.
Other scanners detect if an MR contains a relevant file to be scanned and if there are not changes to those files, the scanner will not run. However, the scanner is properly configured and should not block an MR if the scanner does not run.
These rules should be accounted for as default behavior for a policy set to fail closed
(as defined in &10816 (closed)).
This effort will be an enhancement of &10816 (closed). Failing open will continue to be valuable for rolling out policies where security teams may work across project teams to increase adoption of the policy, without blocking them in the short term.
Intended users
User experience goal
Proposal
Further details
Permissions and Security
Documentation
Availability & Testing
Available Tier
Feature Usage Metrics
What does success look like, and how can we measure that?
What is the type of buyer?
Is this a cross-stage feature?
What is the competitive advantage or differentiation for this feature?
Links / references
This page may contain information related to upcoming products, features and functionality. It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes. Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab Inc.
- Show closed items