GitLab 15.10 released with improved SAST finding resolution
GitLab 15.10 released with the ability to automatically resolve SAST findings when rules are disabled, a new view to see all branch-related settings together, the ability to create and switch branches in the Web IDE Beta, compliance frameworks reports, and much more!
These are just a few highlights from the 115+ improvements in this release. Read on to check out all of the great updates below.
We thank the wider GitLab community for the 170+ contributions they provided to GitLab 15.10! At GitLab, everyone can contribute and we couldn't have done it without you!
To preview what's coming in next month’s release, check out our Upcoming Releases page, which includes our 15.11 release kickoff video.
Mohamed contributed the highly requested feature of creating and editing diagrams in Wikis using the diagrams.net editor. He collaborated with members of GitLab’s product and engineering teams to deliver a robust implementation that follows GitLab’s user experience guidelines.
“Mohamed was very receptive to GitLab team members’ feedback and persevered through the entire code review process,” said Enrique Alcántara, Sr. Frontend Engineer at GitLab.
Matthew Macfarlane, Product Manager at GitLab added that “Mohamed’s contribution helped implement a feature request with 305 upvotes that had been open for over 5 years.”
Mohamed works at JGraph Ltd. as a software engineer and maintains diagrams.net. We thank Mohamed for working on this contribution to GitLab. Congratulations to our 15.10 MVP 🙌
This change helps you focus on the vulnerabilities that are still relevant after the rule update.
Previously, when a rule was no longer scanned, its findings would be marked “No longer detected” but you still had to take action to resolve them.
Now, the Vulnerability Management system automatically resolves those findings and leaves a comment explaining that the rule was removed, so you still have a historical record of the vulnerability.
This change will automatically resolve findings from a small number of rules that we’ve replaced or removed in recent releases.
In this release, we’ve also removed a JavaScript SAST rule that created too many false-positive results.
This feature is enabled by default on GitLab.com and in GitLab 15.10.
On GitLab.com, contact Support if you need to disable the flag for your project.
On GitLab self-managed, you can disable the project-level feature flag named sec_mark_dropped_findings_as_resolved.
From GitLab 15.10, you can configure and validate your projects with Apple App Store credentials. You can then use those credentials in CI/CD pipelines to automate releases to Test Flight and the App Store.
To record your experiences with the App Store integration, see this feedback issue.
All branch-related protections now display on a single page. To see a unified list of your branches and all their protection methods, go to Settings > Repository > Branch rules. Each branch shows the merge request approvals, security approvals, protected branches, and status checks configured for it. Previously, these settings were grouped by type, making it tough to see a holistic view of a specific branch’s protections.
We hope this change helps you discover, use, and monitor these settings more easily. We’d love your feedback in issue #388149.
Identifying commits that have been tagged just got simpler. View the commits list at Repository > Commits to see commits with their tags attached. This view helps you understand what commits have been added since a tagged release commit.
With GitLab 15.10, you can more easily create and edit diagrams in wikis by using the diagrams.net GUI editor. This feature is available in the Markdown editor and the content editor, and was implemented in close collaboration with the GitLab wider community.
When you open the Web IDE Beta from a repository or merge request, the currently selected branch is used by default. You can create a new branch with your changes or, if you’re not on a protected branch, commit to the current branch. Starting with GitLab 15.10, you can now also create a new branch any time while making changes or switch branches in the Web IDE Beta. This way, you can boost your productivity by not having to close the Web IDE Beta to switch contexts.
Previous versions of GitLab provided a compliance report that shows compliance violations.
In GitLab 15.10, we’ve added a compliance framework report so can you see at a glance which compliance frameworks have been applied to the projects in your group.
Since release in closed beta, Suggested Reviewers has been enabled in over 1,000 projects and suggested over 200,000 reviewers. We’ve also made the service more reliable and are now making it generally available to all Ultimate customers.
Deciding the right person to review your merge request isn’t always straightforward or obvious. Choosing the wrong reviewer can cause delays, low quality reviews, back and forth reassigning reviewers, or even no review at all.
Now, GitLab can recommend a reviewer with Suggested Reviewers. Using the changes in a merge request and a project’s contribution graph, machine learning powered suggestions appear in the reviewer dropdown in the merge request sidebar. Suggested Reviewers is our first—of many—fully available ML feature at GitLab.
To protect GitLab and users across the system from any potential abuse or misuse, we’ve implemented a feature to disable group webhooks that fail consistently.
Group webhooks that return response codes in the 5xx range are understood to be failing intermittently and are temporarily disabled. These webhooks are initially disabled for 1 minute, which is extended on each retry up to a maximum of 24 hours.
Group webhooks that fail with 4xx errors are permanently disabled.
Users with the Owner or Maintainer role are alerted in the app to investigate and re-enable any failed group webhooks.
By default, this feature is enabled on GitLab.com and disabled on self-managed GitLab. To enable automated disabling of failed webhooks for project or group webhooks, administrators of self-managed instances must enable the auto_disabling_web_hooksfeature flag.
If you have an existing OAuth application, you can now select Renew secret to generate a new client secret. This improves application security by providing an easy way to get a new secret.
The OpenID Connect (OIDC) OmniAuth provider for authentication in GitLab now supports group claims for administrator, external, and required groups. This is consistent with our SAML implementation, and administrators can use OIDC and group claims to manage upstream user access to GitLab.
When migrating GitLab groups and projects, errors listed as import failures on the group Import history page were not always informative enough.
We now include errors from all nested subrelations to make it clear why a relation (for example, a merge request), failed to import. Better error
messages support debugging and speed up resolution time.
To protect against the risk of data loss and exposure, GitLab administrators can now use outbound request filtering controls to safely manage their instances. With this setting, you can block all requests and define accepted IP addresses and domains in an allowlist to establish secure routes for outbound traffic.
SAML group lock allows GitLab administrators to prevent additional members being added to groups that are controlled by SAML group links. Previously, if SSO enforcement was enabled, a group Owner could add a non-group user to their group if that user has signed in using SSO. If SSO enforcement was not enabled, a group Owner could add any non-group user to their group. Now, if SAML group lock is enabled, users can only be added using SAML group links.
Previously, the GraphQL API supported only one metric per request. Now, it supports multiple DORA metrics in the same request. This change improves performance when querying DORA metrics data.
Gitlab’s DORA metrics help executives who are investing in DevOps transformation to understand the ROI on processes they are implementing and tools they have purchased. The teams can use the changes in these metrics as KPIs.
You can report abuse from other GitLab users to GitLab administrators. Previously, you could report specific comments, for example, in issues and merge requests.
Now you can also report comments in epics.
Before this release, there was no way to see a detailed change log for a task or have discussions directly with team members. Tasks now show system notes and support collaborating with comments and threads.
There are also many improvements to existing commands, and documentation improvements to help both SaaS and self-managed users to get started. For a full list of changes, see the release notes.
Thank you Sebastian and madflow for your contributions!
We’re also releasing GitLab Runner 15.10 today! GitLab Runner is the lightweight, highly-scalable agent that runs your CI/CD jobs and sends the results back to a GitLab instance. GitLab Runner works in conjunction with GitLab CI/CD, the open-source continuous integration service included with GitLab.
Omnibus installations of GitLab run the Kubernetes Agent Server (KAS) on the main GitLab domain. To stay consistent with the GitLab chart installation method, you can now serve KAS to Omnibus installations on a dedicated subdomain.
The KAS address /-/kubernetes-agent on the main GitLab domain remains the default setting.
GitLab Dependency Scanning now supports a new DS_MAX_DEPTH variable to allow users to scan their entire repository for lock files. This variable defaults to only scanning up to two directories deep by default; however, users can set the variable to a larger number or to a value of -1 to scan their entire repository.
GitLab Static Analysis includes many security analyzers that the GitLab Static Analysis team actively manages, maintains, and updates. The following analyzer updates were published during the 15.10 release milestone. These updates bring additional coverage, bug fixes, and improvements.
KICS-based analyzer updated to version 1.6.11. See CHANGELOG for further details. This version includes new rules, bug fixes, and improvements.
PMD Apex-based analyzer updated to version 6.54.0. See CHANGELOG for further details.
Secrets analyzer updated with new rules. See CHANGELOG for further details. New rules include:
Sendinblue SMTP tokens, thanks to a community contribution from @ohemelaar.
SpotBugs-based analyzer updated to improve debug logging. See CHANGELOG for further details.
If you include the GitLab-managed SAST template (SAST.gitlab-ci.yml), you don’t need to do anything to receive these updates. However, if you override or customize your own CI/CD template, you need to update your CI/CD configurations.
To remain on a specific version of any analyzer, you can pin to a minor version of an analyzer. Pinning to a previous version prevents you from receiving automatic analyzer updates and requires you to manually bump your analyzer version in your CI/CD template.
With this release, Geo now automatically verifies the data integrity of a replicated Container Registry. This ensures that container images are not corrupted in transfer or at rest. If Geo is used as part of a disaster recovery strategy, this protects you against data loss.
GitLab 15.10 includes Mattermost 7.8 with updates to Boards filters and groups, and more. This version also includes security updates and upgrading from earlier versions is recommended. For more information, read the upgrade notes.
In GitLab 15.10, we also introduce new public version manifests for Omnibus GitLab. The version manifest file shows the top level software versions, and importantly, where those versions can be fetched from. These files may need to be readily available for different cloud-deploy requirements, so now our release pipelines will generate a public manifest version.
You can now search for users by using Advanced Search. This new functionality not only improves the performance of searching for users, but also gives the ability to refine the search by using Advanced Search syntax.
You can now filter code search results by one or more languages. The new filter uses Elasticsearch aggregations to help you narrow down the results to specific programming languages. To use this feature, Advanced Search must be enabled.
Set the syntax highlighting theme shown to new users, or users who are viewing code but not signed in. Previously, the default only applied to signed-in users, causing signed-out users to sometimes see a visual clash between dark and light theme highlighting.
The open beta release of migrating GitLab projects with
top-level groups by direct transfer meant GitLab self-managed users gained access to the beta feature. However, instance administrators had
to enable both:
An application setting for migrating groups.
The bulk_import_projects feature flag for migrating projects in the groups.
In this release, we have removed the feature flag so you only need the application setting.
This change also enables GitLab Dedicated instances to take advantage of the feature.
This release includes a new section dedicated to browsing and discovering various content within GitLab. This new section, called Explore, helps you view and search across different content types. Previously, it was difficult to switch between types while searching for content.
Also with this change, the Topics section is elevated to the Explore section. This change should better accommodate the feature and its discoverability. This change helps promote open source while helping you find content related to topics you are interested in.
Until now, imported GitHub projects didn’t have their collaborators imported with them. This meant that no users had any
permissions on these projects. As a workaround, group owners would add members before the import.
Now, if a collaborator’s role can be mapped to a GitLab role, GitLab adds the GitHub collaborator to the imported project as a GitLab project member.
When users are provisioned with SAML or SCIM, the link in their email confirmation now directs them to sign in through their identity provider. Previously, users were directed to the GitLab sign-in page, which was potentially confusing.
GitLab sends a notification email when your account is signed into from an unknown location. Previously, this email did not include name information, making it difficult to tell which account the notification was associated with. This notification email now includes both the user’s full name and username.
Previously, you had to use a time-based one-time password (TOTP) before you could add a WebAuthn device as a two-factor authentication (2FA) method on your GitLab account. Now, you can add a WebAuthn device as your 2FA method without having to use a TOTP. You must download recovery codes when adding a WebAuthn device as your 2FA method so you can recover access to your account if you are locked out.
To improve the tracking of development workflows in Value Stream Analytics, we added a new pairing rule for customizable stages between MR label events and MR merged events. This rule makes it possible to create a custom stage that, for example, measures the time from when an MR was labeled as workflow::in review to when it was merged.
Define a default code owner for each section of your CODEOWNERS file. This default
now applies to files and directories referenced in the section. This way you don’t
have to repeat the same owners over and over. Individual files and directories can
still be overridden.
In this example, all files and directories are owned by @dev-team, except README.md
and the data-models/ directory.
Merge Trains allow you to sequence merge requests (MRs) and verify their changes work together before they are merged to the target branch. Previously, to add an MR to a merge train, you had to click a button on the MR’s page in the GitLab UI. This method did not support CI/CD automation or other flows that some organizations might want to implement.
Now you can add a merge request to a merge train by using the merge trains API, enabling more control through automation.
The GitLab agent for Kubernetes manages access with agent access tokens. Because they can be used to update your cluster from GitLab, you should regularly rotate your agent tokens. GitLab now triggers audit events when the agent access tokens are created or revoked to support your security and compliance requirements.
Customer support agents often send screenshots and other files to external Service Desk issue authors.
However, if your GitLab instance is not reachable from the internet or if you are using a private project that requires
authentication to access issue uploads, issue authors won’t be able to access the assets.
In this release, files up to 10 MB attached to comments on Service Desk issues are sent to external participants as native email attachments.
This allows external issue authors to access the
assets directly in their inboxes without having to access the attachments through GitLab.
The new method of License Compliance scanning is now fully supported for self-managed GitLab instances, including instances that are running in an offline environment. This feature is behind two feature flags that are disabled by default. To try this feature, enable the license_scanning_sbom_scanner and package_metadata_synchronization feature flags, and replace the Jobs/License-Scanning.gitlab-ci.yml template in your CI configuration with the Jobs/Dependency-Scanning.gitlab-ci.yml template. In GitLab 16.0 and later, the old method of scanning with the Jobs/License-Scanning.gitlab-ci.yml template will no longer be supported.
Users can now require SAST IaC scans to run on a regular schedule or as part of project CI pipelines, independent of the .gitlab-ci.yml file’s contents. This allows security teams to manage these scan requirements separately, without allowing developers to change the configuration. You can get started by creating a scan execution policy on the Security & Compliance > Policies page.
GitLab 15.10 introduces a new certificates container certificates built off of gitlab-base. Previously, they were built on top of Alpine Linux and named alpine-certificates.
GitLab 15.10 also introduces smaller images for Cloud Native UBI8. These images have been made smaller by adopting UBI Minimal allowing for more rapid deployments. This is part of a larger initiative to reduce the number and severity of vulnerabilities across GitLab container images.
Users with the Owner or Maintainer role for a project can now use the GraphQL API to change the maximum access level of non-inherited users of a project. This release brings more administrative features to users with the Owner or Maintainer role for projects on GitLab.com, and lays the foundation for future administrative bulk actions.
When editing a project in the Admin Area, users are currently redirected to the project settings page of the respective project.
This redirect requires several clicks to return to the original list of of projects, thus making it cumbersome for an administrator who tries to edit multiple projects.
To improve this workflow, a new project edit page is introduced that allows administrators to stay in the Admin Area when editing a project, and to return to the project list with just one click.
Bug fixes, performance improvements, and UI improvements
At GitLab, we’re dedicated to providing the best possible experience for our users. With every release, we work tirelessly to fix bugs, improve performance, and enhance UI. Whether you’re one of the over 1 million users on GitLab.com or using our platform elsewhere, we’re committed to making sure your time with us is smooth and seamless.
Click the links below to see all the bug fixes, performance enhancements, and UI improvements we’ve delivered in 15.10.
We want to hear from you
Enjoyed reading this blog post or have questions or feedback? Share your thoughts by creating a new topic in the GitLab community forum.
Share your feedback