With every GitLab release we enhance and optimize security and governance solutions to ensure customers have the tools they need to produce secure and compliant software. Our values of iteration and results for customers drive our release cycles, and GitLab 17 is no exception. We have been releasing every month for the past 153 months straight!
In this article, you'll learn my favorite security and governance enhancements released in GitLab 17 and 17.1 and how they can benefit your organization’s security requirements.
- SAST analyzer streamlining
- Android dependency scanning
- Custom roles and granular security permissions updates
- Secret detection updates
- Container registry updates
- API security scanning updates
SAST analyzer streamlining
GitLab provides static application security testing (SAST) to examine your source code for known vulnerabilities, detecting vulnerabilities such as SQL injections and cross-site scripting. When SAST kicks off, the programming language used is auto-detected and the appropriate scanner is loaded.
In GitLab 17, SAST scans the same languages, but now with fewer analyzers, offering a simpler and more customizable experience. Language-specific analyzers have been replaced with GitLab-managed rules in the Semgrep-based analyzer for the following languages:
- C/C++
- Swift (iOS)
- Java/Kotlin (Android)
- Node.js
- PHP
- Ruby
Having one analyzer for many different languages makes configurations and writing rules easier than ever. See the supported languages and frameworks documentation for more information.
Watch this video to learn more:
Android dependency scanning
In modern software development, many applications are built from multiple dependencies that are best at performing their intended function. For example, rather than writing a YAML parser, a developer will use a library that parses YAML. This allows developers to focus on the main goal of their application, rather than spending time on utility functions.
While the use of dependencies speeds up efficiency, they can be difficult to manage and could introduce vulnerabilities to your application. For this, GitLab provides dependency scanning, which analyzes dependencies for known vulnerabilities.
Many organizations are using dependencies even when creating native mobile applications. In GitLab 17, we introduced Android dependency scanning to bridge the gap. Android dependency scanning can be easily added as a CI/CD catalog component – just include the following code in your .gitlab-ci.yml:
include:
- component: gitlab.com/components/android-dependency-scanning/[email protected]
inputs:
stage: test
This job will also generate a CycloneDX software bill of materials (SBOM) report, which may be necessary for compliance. Make sure to scan your Android dependencies as soon as possible, as there are many CVEs out there.
Watch this video to learn more:
Learn more SBOMs and dependencies with our ultimate guide to SBOMs.
Custom roles and granular security permissions updates
GitLab provides custom roles to allow organizations to create user roles with the precise privileges and permissions to meet their needs. This enables organizations to implement the principle of least privilege to adhere to various compliance standards.
In GitLab 17, managing custom roles has become easier than ever. You can now edit a custom role and its permissions directly from the UI, whereas, in the past, the role needed to be recreated. Also, for those using GitLab self-managed, custom roles are now managed at the instance level, allowing administrators to create the roles, and group owners to assign them.
Watch this video to learn more:
There have also been several UX improvements added to this feature along with the introduction of the following permissions:
- assign security policy links
- manage and assign compliance frameworks
- manage webhooks
- manage push rules
- manage merge request settings (17.1)
- manage integrations (17.1)
- manage deploy tokens (17.1)
- read CRM contacts (17.1)
GitLab releases usually include new permissions to further enable the implementation of the principle of least privilege. To learn more about the available granular security permissions, visit the available custom permission documentation.
Secret detection updates
Developers may accidentally commit secrets like keys or API tokens to Git repositories from time to time. After a sensitive value is pushed to a remote repository, anyone with access to the repository can impersonate the authorized user of the secret and cause mayhem. When this occurs the exposed secrets must be revoked and replaced to address this risk, which can cause system downtime.
GitLab provides secret detection to address this risk, and in GitLab 17 it’s gotten even better with the following enhancements:
- Support for remote rulesets when overriding or disabling rules: - Allows you to override or disable rules via a remote configuration. Therefore, you can scale rule configurations across multiple projects using only one TOML file.
- Advanced vulnerability tracking: Detects when the same secret has moved within a file due to refactoring or unrelated changes. This leads to reduced duplicate findings, simplifying vulnerability management.
In GitLab 17.1, secret push protection is now in Beta. Secret push protection checks the content of each commit pushed to GitLab. If any secrets are detected, the push is blocked and displays information about the commit. Therefore, a developer does not need to do the extra work of removing and rotating secrets, since they are never committed upstream.
When push protection occurs, you can see it displays additional information on the commit, including:
- the commit ID that contains the secret
- the filename and line number that contains the secret
- the type of secret
Note: Enabling secret push protection is as easy as flipping a switch in GitLab Security Configuration.
Watch this video to learn more:
Container registry updates
GitLab provides a built-in container registry, making it easy for developers to store and manage container images for each GitLab project without context switching. GitLab 17.1 includes several features to enhance the security and efficiency of using the registry:
- Container images linked to signatures: Container images in the registry can now be signed and associated with the signature. This can reduce image tampering by allowing developers to quickly find and validate the signatures that are associated with a container image
- Display the last published date for container images: The container registry UI has been updated to include accurate
last_published_at timestamps, putting critical data at the top of view. - Sort container registry tags by publish date: Allows developers to quickly find and validate the most recently published container image.
Additionally we’ve introduced container scanning for the registry. The container images being used in your application may themselves be based on other container images that contain known vulnerabilities. Since developers heavily make use of the built-in container registry, it is a no-brainer to introduce container scanning for the registry.
Container scanning for the registry can be easily enabled by flipping a switch in GitLab Security Configuration. Once it’s enabled, whenever a container image is pushed to the container registry in your project, GitLab checks its tag. If the tag is latest, then GitLab creates a new pipeline that scans the image and even produces a CycloneDX SBOM.
Note: At the moment, a vulnerability scan is only performed when a new advisory is published. We are working to detract all vulnerabilities in the registry itself in future iterations.
Watch this video to learn more:
API security scanning updates
While SAST does a great job of finding vulnerabilities in static source code, there can still be vulnerabilities present in the running application that cannot be detected in source code, such as broken authentication and security misconfigurations. For these reasons, GitLab provides dynamic application security testing (DAST) and Web API fuzzing to help discover bugs and potential security issues that other QA processes may miss.
In GitLab 17, we’ve introduced several enhancements to our dynamic scanners which target Web APIs, including:
- system environment variables are now passed from the CI runner to the custom Python scripts used for certain advanced scenarios (like request signing)
- API Security containers now run as a non-root user, which improves flexibility and compliance
- support for servers that only offer TLSv1.3 ciphers, which enables more customers to adopt API security testing.
- scanner image upgraded to Alpine 3.19, which addresses security vulnerabilities
In GitLab 17.1, additional configuration variables were added to API security scanning and API fuzzing to allow:
- creation of a comma-separated list of HTTP success status codes that define whether the job has passed
- disabling of waiting for the target API to become available before scanning begins
- specifying the expected status code for the API target availability check
Watch this video to learn more:
Learn more about other enhancements
GitLab 17 and 17.1 also introduced several other security and governance features and enhancements, too many to cover in this blog. Some of these features include:
- Updated filtering on the Vulnerability Report: You can now use the filtered search component to filter the Vulnerability Report by any combination of status, severity, tool, or activity.
- Toggle merge request approval policies to fail open or fail closed: A new fail open option for merge request approval policies to offer flexibility to teams who want to ease the transition to policy enforcement as they roll out controls in their organization.
- Optional configuration for policy bot comment: The security policy bot posts a comment on merge requests when they violate a policy to help users understand when policies are enforced on their project, when evaluation is completed, and if there are any violations blocking an MR, with guidance to resolve them.
- Merge request approval policies fail open/closed (policy editor): Within the policy editor users can now toggle security policies to fail open or fail closed. This enhancement extends the YAML support to allow for simpler configuration within the policy editor view.
- Project owners receive expiring access token notifications: Both project owners and maintainers with direct membership now receive email notifications when their project access tokens are close to expiring. This helps keep more people informed about upcoming token expiration.
These are some of the newest security and compliance enhancements provided in GitLab 17 and 17.1 that can be applied to strengthen your organization's security posture! To learn more about GitLab and the other ways we can strengthen your organization's security throughout all parts of the software development lifecycle, check out the following links:
