GitLab.org/GitLab: Release v14.4.0-ee
Name: GitLab
Owner: GitLab.org
Release: GitLab 14.4
Released: 2021-10-22
License: MIT
Release Assets:
[SAML `nickname` and `username` assertions on GitLab.com](https://docs.gitlab.com/ee/user/group/saml_sso/#assertions) (SaaS only):
> Previously, usernames in SAML assertion attributes on GitLab.com were derived from the
> user's email address. Now the user's GitLab.com username is used when the SAML response
> includes a `username` or `nickname` attribute. This allows for more flexibility in defining GitLab usernames when using an Identity Provider.
Authentication and Authorization[Slack notifications for new vulnerabilities](https://docs.gitlab.com/ee/user/project/integrations/slack.html#slack-notifications-service):
> The Slack integration in GitLab now has the option to create a notification when a new vulnerability is detected. This ensures that the right team members are notified and new vulnerabilities get the proper level of attention.
Integrations[Requirements navigation now under Issues](https://docs.gitlab.com/ee/user/project/requirements/):
> As part of our effort to streamline our top-level navigation within projects, we have moved Requirements into the Issues menu. This move aligns with our vision to align our navigation to common tasks and reduce the number of top-level navigation items by grouping functionality under sub-menu items when possible.
Navigation & Settings, Requirements Management[Sorting for DevOps Adoption table](https://docs.gitlab.com/ee/user/group/devops_adoption/):
> DevOps Adoption just got better. You can now sort groups and subgroups in the DevOps Adoption table by column name, making it easier for you to locate the group you're interested in.
DevOps Reports[DevOps Adoption trend graph](https://docs.gitlab.com/ee/user/group/devops_adoption/#adoption-over-time):
> In GitLab 14.4, we added a new graph to group-level DevOps Adoption for trend over time. This graph shows you how groups adopt DevOps features over time and can give insights into how quickly groups are adopting additional DevOps processes. This is broken down by Dev, Sec, and Ops functionality.
Value Stream Management[Directly create vulnerability records via API](https://docs.gitlab.com/ee/api/graphql/reference/#mutationvulnerabilitycreate):
> GitLab's vulnerability management capabilities make it easy to triage and remediate security issues detected by our [security scanning tools](https://docs.gitlab.com/ee/user/application_security/#security-scanning-tools) or from integrated 3rd-party tools. One limitation of this approach is that the vulnerability data can only come from the output of one of these tools. Organizations wishing to pull in other vulnerability source information currently do not have a simple option for doing so.
>
> We are addressing this limitation with the introduction of new GraphQL properties for vulnerability object creation. You now have a way to programmatically add external vulnerability records directly to your projects. Combined with our existing GraphQL capabilities for vulnerability management, this opens up many new automation opportunities, such as syncing with an external bug bounty program or adding findings from security tools that may not be suitable for pipeline jobs, providing a more comprehensive view of a project's security vulnerabilities.
Vulnerability Management[Scheduled DAST scans](https://docs.gitlab.com/ee/user/application_security/dast/index.html#schedule-an-on-demand-scan):
> GitLab’s Dynamic Application Security Testing (DAST) now supports scheduled on-demand scans. Previously, on-demand DAST scans could only be manually triggered, which limited the usability to scans that you wanted to run immediately. With this new scheduler, you can set a DAST scan to run either once at a specific time in the future, or on a recurring basis. If adding DAST to your pipelines is not an option for your organization, or if the security or compliance regulations for your area require a scan to be scheduled, this feature provides an easy way to create a scheduled scan to meet your needs. The scan can be associated with the default branch, which allows for the results to show on the Secure Dashboard and Vulnerability list. Combined with the scan and site profiles, the scheduled on-demand scans give you quick and easy access to DAST results for your application or API, on a schedule that works for your development and security teams.
DAST[Filter scoped labels with a wildcard](https://docs.gitlab.com/ee/user/project/labels.html#filter-by-scoped-labels):
> Filter scoped labels with a wildcard to quickly find issues, epics, or merge requests that all share the same key from a set of scoped labels. You can also pair wildcard filtering with `!=` (is not) to easily filter down items that do not have any label from a set of scoped labels. To filter with a wildcard, just append `*` after typing in your scoped label key (for example, `label::*`).
Team Planning[GitLab chart improvements](https://docs.gitlab.com/omnibus/update/gitlab_14_changes.html#downgrading-grafana-from-81-to-75) (self-managed only):
> - In GitLab 14.4 we have downgraded Grafana from 8.1.3 to 7.5.11, see more details [here](https://docs.gitlab.com/omnibus/update/gitlab_14_changes.html#downgrading-grafana-from-81-to-75).
Cloud Native Installation[Omnibus improvements](https://docs.gitlab.com/omnibus/update/gitlab_14_changes.html#downgrading-grafana-from-81-to-75) (self-managed only):
> GitLab 14.4 includes these Omnibus improvements:
>
> - Grafana downgrade from 8.1.3 to 7.5.11. For more information, see the [changes documentation](https://docs.gitlab.com/omnibus/update/gitlab_14_changes.html#downgrading-grafana-from-81-to-75).
> - [Mattermost 5.39](https://mattermost.com/blog/mattermost-v5-39/). Mattermost is an open source Slack alternative. Its newest release contains a low-level security fix and other improvements, such as improvements to collapsed reply threads.
Omnibus Package[More paid features available to free users](https://docs.gitlab.com/ee/development/service_ping/index.html#registration-features-program):
> As a follow-up iteration to the [Registration Features](https://docs.gitlab.com/ee/development/service_ping/index.html#registration-features-program)
> program released in 14.1, we've added two more paid features for free GitLab self-managed users running GitLab EE. Simply register with GitLab and send us activity data through [Service Ping](https://docs.gitlab.com/ee/development/service_ping/index.html#what-is-service-ping), and you can enjoy these additional features for free:
>
> - [Limit project size at a global, group, and project level](https://docs.gitlab.com/ee/administration/settings/account_and_limit_settings.html#repository-size-limit).
> - [Restrict group access by IP address](https://docs.gitlab.com/ee/user/group/#restrict-group-access-by-ip-address).
Product Analytics[Sorting for project-level Value Stream Analytics](https://docs.gitlab.com/ee/user/analytics/value_stream_analytics.html):
> Value Stream Management for projects just got better. You can now sort the work items in a stage by time or name. We've also added pagination to make it easier to locate and display the issues you're interested in.
Value Stream Management[Resource group process mode](https://docs.gitlab.com/ee/ci/resource_groups/#process-modes):
> Setting a resource group in your CI/CD job enables you to prevent the same job from running concurrently when the same pipeline runs in parallel. This can happen if for example, you push multiple commits in very short intervals. Running multiple deployment scripts to the same infrastructure could harm your instance and leave it in a corrupted state in the worst case scenario. By default, the process mode of a resource group is set to `unordered`, which means that a job runs whenever it's ready to run.
>
> In GitLab 14.4, we added two more process modes that are useful when you want to enforce a specific execution order of the jobs: `oldest_first` and `newest_first`. By setting the process mode with one of these new options, the system will enforce the execution of jobs in FIFO (First in First Out) order, or LIFO (Last in First Out) order, respectively.
Continuous Delivery, Release Orchestration[The GitLab Operator is Generally Available](https://docs.gitlab.com/operator/) (self-managed only):
> GitLab 14.4 is proud to announce the general availability of [the GitLab Operator](https://about.gitlab.com/blog/2021/10/12/open-shift-ga/), with the ability to run production instances of GitLab on Kubernetes platforms, including Red Hat OpenShift. The GitLab Operator also automates day 2 operations such as upgrading components, application reconfiguration, and autoscaling. Check out the [GitLab Operator installation documentation](https://docs.gitlab.com/operator/) for additional information.
Cloud Native Installation[Custom commit message for batch suggestions](https://docs.gitlab.com/ee/user/project/merge_requests/reviews/suggestions.html):
> Suggesting changes to a merge request makes code review faster and easier by quickly proposing changes and applying the given feedback at a click of a button. In GitLab 13.9, we made this experience even better by allowing users to specify a [custom commit message for suggested changes](https://about.gitlab.com/releases/2021/02/22/gitlab-13-9-released/#apply-a-suggestion-with-a-custom-commit-message) to improve workflows that require custom commit messages. However this wasn't available for [batch suggestions](https://docs.gitlab.com/ee/user/project/merge_requests/reviews/suggestions.html#batch-suggestions), which meant users needed to either apply suggestions individually or resort to squashing all commits locally prior to merge.
>
> You can now write a custom commit message when applying batch suggestions. This allows authors and contributors to accept suggestions and follow commit message best practices for their projects. It also helps to reduce the number of commits by applying all the suggestions as a single commit with the desired message. If no custom commit message is specified, the suggestion is committed with a default commit message.
Code Review[Edit the current file with a single keystroke](https://docs.gitlab.com/ee/user/project/web_ide/):
> Now it's even easier to take advantage of the powerful Web IDE and contribute to a project from your web browser. Simply press the `.` (dot) key on your keyboard to open the Web IDE with the current context loaded and ready to edit. Whether you're navigating individual files in the repository or reviewing a merge request, this is a great way to start editing without taking your hand off the keyboard.
Web IDE, Source Code Management[Remote Repositories for GitLab in Visual Studio Code](https://gitlab.com/gitlab-org/gitlab-vscode-extension/-/blob/main/README.md#browse-a-repository-without-cloning):
> When working in your editor you may need to refer to another project or upstream library for additional information. When you don't have that project already cloned locally, you're forced to either leave your editor and browse the project on GitLab, or locate and then clone the project so you can browse it in your editor. Both of those tasks break your current context, introduce delays, and can take you to a less familiar interface for working with code.
>
> [GitLab Workflow](https://marketplace.visualstudio.com/items?itemName=GitLab.gitlab-workflow) version `3.33.0` provides an option to open a remote repository. Open the command palette and use the `GitLab: Open Remote Repository` command to find and then open a project.
>
> Opening a remote repository allows you to browse a read-only version of a project in your familiar VS Code environment. You can then quickly find the information you're looking for, compare an implementation, or copy a snippet you need.
>
> Thanks to [Ethan Reesor](https://gitlab.com/firelizzard) for the amazing work and numerous merge requests required in contributing this feature!
Editor Extension[Improve security of `CI_JOB_TOKEN` with bots and more](https://docs.gitlab.com/ee/ci/jobs/ci_job_token.html#limit-gitlab-cicd-job-token-access):
> The `CI_JOB_TOKEN` CI/CD variable makes API calls more intuitive within CI/CD jobs, enabling advanced automation. For example, the token can be used with bot automation projects that run pipelines in other projects. The token is short-lived, but in an effort to make its usage even more secure we are adding a setting that lets you list the exact projects that can be accessed with your project's CI job token. If the token is used to try to access other projects, it will be denied access to the API. In the bot automation example, it gives you additional control over the exact projects your bot will have access to and an added layer of security when using the `CI_JOB_TOKEN` CI/CD variable.
>
> This setting is currently disabled by default to avoid impacting existing projects but we strongly recommend enabling it in all your existing projects.
Continuous Integration (CI)[Limit the runners registered to a group or project](https://docs.gitlab.com/ee/administration/instance_limits.html#number-of-registered-runners-per-scope):
> In GitLab 13.12, we started rolling out this feature, limiting the number of runners registered to a group or project. As of 14.4, this feature is now fully enabled on GitLab.com and limits the number of registered runners to 1,000. For self-managed administrators, this means you can implement limits at the group and project level, which will help reduce the administrative overhead resulting from teams registering new runners while not removing inactive runners.
GitLab Runner[GitLab Runner 14.4](https://docs.gitlab.com/runner):
> We're also releasing GitLab Runner 14.4 today! GitLab Runner is the lightweight, highly-scalable agent that runs your build 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.
>
> #### Bug Fixes:
>
> - [Pod label name cannot contain special characters with Kubernetes executor](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/4565).
> - [GitLab Runner ignores the runtime configuration for service containers](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/27168).
> - [Consider all Docker image pull errors as a script failure rather than a system failure](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/28075).
> - [S3 cache failure in AWS China (Beijing) region](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/28085).
>
> The list of all changes is in the GitLab Runner [CHANGELOG](https://gitlab.com/gitlab-org/gitlab-runner/blob/14-4-stable/CHANGELOG.md).
GitLab Runner[Cleanup policies for the Dependency Proxy](https://docs.gitlab.com/ee/user/packages/dependency_proxy/#cleanup-policies):
> You can use the GitLab Dependency Proxy to proxy and cache container images from Docker Hub for faster, more reliable builds. The problem is that, over time, your team may add a lot of items to the cache. This can result in higher storage costs.
>
> You've been able to work around this by using the [API](https://docs.gitlab.com/ee/api/dependency_proxy.html) to purge the entire cache. But that's inefficient because you only want to remove old, stale items that are no longer in use. That's why we've added cleanup policies for the Dependency Proxy. Now you can programmatically delete image tags from the cache that haven't been recently used by your team.
>
> Simply configure the number of days and all cached dependency proxy files that have not been pulled in that many days are deleted. We recommend 90 days as a good starting point. The cleanup policies for the Dependency Proxy can be set using the GitLab GraphQL API. We're currently working on [adding this setting to the user interface](https://gitlab.com/gitlab-org/gitlab/-/issues/340777) as well.
Dependency Proxy[Semgrep SAST Analyzer for Go](https://docs.gitlab.com/ee/user/application_security/sast/#supported-languages-and-frameworks):
> In GitLab 13.12 we [released Semgrep for Javascript, TypeScript, and Python](https://about.gitlab.com/releases/2021/05/22/gitlab-13-12-released/#semgrep-sast-analyzer-for-javascript-typescript-and-python). Today we're expanding the Semgrep analyzer to support projects written in the Go language.
> With 14.4, we're updating our managed `SAST.gitlab-ci.yml` CI template to automatically run this new analyzer alongside our existing Go analyzer, [GoSec](https://gitlab.com/gitlab-org/security-products/analyzers/gosec). In a future release, we will fully disable GoSec, but for now it will work in unison with Semgrep. We've done work to deduplicate findings, so you should not notice any difference in findings. If you include our `SAST.gitlab-ci.yml`, you don't need to do anything to start benefiting from the Semgrep Go analyzer. However, if you override or manage your own SAST CI configuration, [you should update your CI configuration](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Jobs/SAST.gitlab-ci.yml#L236).
> We are excited about the future of this transition to bring you fast and wide coverage Static Application Security Testing (SAST). We'll continue to expand the Semgrep analyzer through new security detection rules as well as expanding coverage to other languages. We've created a [feedback issue](https://gitlab.com/gitlab-org/gitlab/-/issues/330578) where you can share your experience with this transition or ask questions.
SAST[Static Analysis analyzer updates](https://docs.gitlab.com/ee/user/application_security/sast/analyzers):
> GitLab Static Analysis is comprised of a [set of many security analyzers](https://docs.gitlab.com/ee/user/application_security/sast/#supported-languages-and-frameworks) that the GitLab Static Analysis team actively manages, maintains, and updates. Below are the analyzer updates released during 14.4. These updates bring additional coverage, bug fixes, and improvements.
>
> - Semgrep updated to version 0.69.1 ([MR](https://gitlab.com/gitlab-org/security-products/analyzers/semgrep/-/merge_requests/82), [Changelog](https://gitlab.com/gitlab-org/security-products/analyzers/semgrep/-/blob/199c1b81fb25156b62c3ebf4a83a08c29365e0ae/CHANGELOG.md)).
> - Reverted change to exclude minified files from the scan.
> - Flawfinder updated to version 2.14.5 ([MR](https://gitlab.com/gitlab-org/security-products/analyzers/flawfinder/-/merge_requests/68/), [Changelog](https://gitlab.com/gitlab-org/security-products/analyzers/flawfinder/-/merge_requests/68/diffs#diff-content-ab09011fa121d0a2bb9fa4ca76094f2482b902b7)).
> - Adds 2 new detection rules.
> - MobSF updated to version 2.13.2 ([MR](https://gitlab.com/gitlab-org/security-products/analyzers/mobsf/-/merge_requests/38), [Changelog](https://gitlab.com/gitlab-org/security-products/analyzers/mobsf/-/blob/4080792719028383d7e4c3153d8eefc426b3c7e6/CHANGELOG.md)).
> - Updates Linux OS packages to the latest versions.
> - pmd-apex updated to version 6.3.9 ([MR](https://gitlab.com/gitlab-org/security-products/analyzers/pmd-apex/-/merge_requests/70), [Changelog](https://gitlab.com/gitlab-org/security-products/analyzers/pmd-apex/-/blob/771412c0cd2569fbd6d02740b2ebaeaec179fa5b/CHANGELOG.md#v2126)).
>
> If you [include the GitLab-managed vendored SAST template](https://docs.gitlab.com/ee/user/application_security/sast/#configure-sast-in-your-cicd-yaml) ([`SAST.gitlab-ci.yml`](https://gitlab.com/gitlab-org/gitlab/blob/master/lib/gitlab/ci/templates/Security/SAST.gitlab-ci.yml)), you do not need to do anything to receive these updates. However, if you override or customize your own CI template, you must update your CI configurations. If you want to remain on a specific version of any analyzer, you can now [pin to a minor version of an analyzer](https://docs.gitlab.com/ee/user/application_security/sast/#pinning-to-minor-image-version). Pinning to a previous version prevents you from receiving automatic analyzer updates and requires you to manually bump your analyzer version in your CI template.
SAST, Secret Detection[Disable auto-resolving of Secret Detection findings introduced in Merge Requests](https://docs.gitlab.com/ee/user/application_security/secret_detection):
> The current implementation of Secret Detection automatically resolves findings (marking them as fixed) for every secret detection scan that is run by diffing between pipeline executions. With the introduction of [historic secret scanning](https://docs.gitlab.com/ee/user/application_security/secret_detection/#full-history-secret-detection) in [GitLab 13.0](https://about.gitlab.com/releases/2020/05/22/gitlab-13-0-released/#secret-detection-for-the-full-history-of-a-repository) we do not want to automatically resolve findings because this effectively erases secret vulnerabilities that are still present in the Git history.
> This change in behavior will improve the usability of the historic secret detection while also providing more clear audit trails for normal secret detection and align the [vulnerability management](https://docs.gitlab.com/ee/user/application_security/security_dashboard/) of secret detection findings with our other security scanners.
Secret Detection[Integrated error tracking inside GitLab without a Sentry instance](https://docs.gitlab.com/ee/operations/error_tracking.html#integrated-error-tracking):
> Prior to GitLab 14.4, you could integrate with Sentry Error Tracking by supplying an endpoint for a Sentry backend (either self-deployed or in their cloud service). With Gitlab 14.4, you now have access to a Sentry-compatible backend built into your GitLab instance. This allows you to quickly instrument your apps so your errors show up directly in GitLab without the need for a separate Sentry instance.
Error Tracking