Customise compliance frameworks with requirements and compliance controls
Customise compliance frameworks with requirements and compliance controls
Previously, compliance frameworks in GitLab could be created as a label to identify that your project has certain compliance requirements or needs additional oversight. This label could then be used as a scoping mechanism to ensure that security policies could be enforced on all projects within a group.
In this release, we are introducing a new way for compliance managers to get more in-depth compliance monitoring in GitLab through ‘requirements’.
With requirements, as part of a custom compliance framework, you can define specific requirements from a number of different compliance standards, laws, and regulations that must be followed as an organization.
We are also expanding the number of compliance controls (previously known as compliance checks) that we offer from five to over 50! These 50 out-of-the-box (OOTB) controls can be mapped to the compliance framework requirements.
These controls check particular project, security, and merge request settings across your GitLab instance to help you meet requirements under a number of different compliance standards, laws, and regulations such as SOC2, NIST, ISO 27001, and the GitLab CIS Benchmark.
Adherence to these controls are reflected in standard adherence report, which is redesigned to take into account requirements and the mapping of controls to those requirements.
In addition to expanding our OOTB controls, we now allow users to map requirements to external controls, which can be for items, programs, or systems that exist outside the GitLab platform. These mappings allow you to use the GitLab compliance centre as the single source of truth when it comes to your compliance monitoring and audit evidence needs.
Enhance security with protected container tags
Enhance security with protected container tags
Container registries are critical infrastructure for modern DevSecOps teams. Until now, GitLab users with the Developer role or higher could push and delete any container tag in their projects, creating risks of accidental or unauthorized changes to production-critical container images.
With protected container tags, you now have fine-grained control over who can push or delete specific container tags. You can:
- Create up to five protection rules per project.
- Use RE2 regex patterns to protect tags like
latest, semantic versions (for example,v1.0.0), or stable release tags (for example,main-stable). - Restrict push and delete operations to Maintainer, Owner, or Administrator roles.
- Prevent protected tags from being removed by cleanup policies.
This feature requires the next-generation container registry, which is already enabled by default on GitLab.com. For GitLab Self-Managed instance, you’ll need to enable the metadata database to use protected container tags.
Safeguard your registry with protected Maven packages
Safeguard your registry with protected Maven packages
We’re thrilled to introduce support for protected Maven packages to enhance the security and stability of your GitLab package registry. Accidental modification of packages can disrupt the entire development process. With protected packages, you can safeguard your most important dependencies against unintended changes.
In GitLab 17.11, you can now protect Maven packages by creating protection rules. If a package matches a protection rule, only specified users can push new versions of the package. Package protection rules prevent accidental overwrites, improve compliance with regulatory requirements, and reduce the need for manual oversight.
Protected packages support for Maven and other package formats are all community contributions from gerardo-navarro and the Siemens crew. Thank you, Gerardo, and the rest of the crew from Siemens for their many contributions to GitLab! If you want to learn more about how Gerardo and the Siemens crew contributed this change, check out this video in which Gerardo shares his learnings and best practices for contributing to GitLab based on his experience as an external contributor.
