Skip to content
Snippets Groups Projects

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

    Open Epic created by Grant Hickman

    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.

    Edited by Grant Hickman

    Linked items 0

  • Link items together to show that they're related or that one is blocking others.

    Activity

    • All activity
    • Comments only
    • History only
    • Newest first
    • Oldest first