GitLab.org/GitLab: Release v14.6.0-ee
Name: GitLab
Owner: GitLab.org
Release: GitLab 14.6
Released: 2021-12-22
License: MIT
Release Assets:
#### [Ultimate](https://about.gitlab.com/pricing/ultimate/)
[Set maximum SSH key lifetime](https://docs.gitlab.com/ee/administration/settings/account_and_limit_settings.html#limit-the-lifetime-of-ssh-keys) (self-managed only):
> Administrators can now set a maximum number of days that an SSH key can remain valid. This is especially useful for organizations that
> are required to enforce SSH key expiration after a given interval for compliance reasons. GitLab
> [already had the ability](https://docs.gitlab.com/ee/administration/settings/account_and_limit_settings.html#limit-the-lifetime-of-personal-access-tokens)
> to set a maximum number of days that Personal Access Tokens (PATs) can remain valid and this feature works in a similar way.
>
> To set this new limit, administrators can navigate to the Admin Area and select **Settings > General**. Find the new setting by expanding
> **Account and limit** to set **Maximum allowed lifetime for SSH keys (in days)**.
Compliance Management[Variable DS_EXCLUDED_PATHS behaviour changed to pre-filter](https://docs.gitlab.com/ee/user/application_security/dependency_scanning/#configuring-dependency-scanning):
> For users of the Dependency Scanning variable `DS_EXCLUDED_PATHS`, it will now pre-filter. Dependency Scanning now considers `DS_EXCLUDED_PATHS` when searching for supported projects and will pre-filter out those that match. Pre-filtering prevents the analyzer from logging warnings or failing when processing dependency files that have been explicitly excluded using `DS_EXCLUDED_PATHS`. This enables users to skip dependency files and build files if desired, and can lead to a performance increase in some cases.
>
> This change was made December 2, 2021 for gemnasium, December 6, 2021 for gemnasium-python and December 7, 2021 for gemnasium-maven. This change applies to all versions as the change is backported.
>
> You should not need to take any action, however if you were expecting this post-filtering behavior, and wrote custom tooling to handle that, you will need to adjust your custom tools. For example, before this change you may have needed to manually or, through the use of a script, delete specific files to avoid a warning or error occurring.
>
> The previous behavior was causing failures and unexpected errors for users and after discussions we found that this, pre-filter as opposed to post-filter, was the more expected and desired behaviour.
Dependency Scanning[Custom ruleset composability for SAST and Secret Detection](https://docs.gitlab.com/ee/user/application_security/sast/#customize-rulesets):
> We're making improvements to our Custom Rulesets capabilities for SAST and Secret Detection which were [introduced in GitLab 13.5](https://about.gitlab.com/releases/2020/10/22/gitlab-13-5-released/#customizing-sast--secret-detection-rules). Custom Rulesets let users tailor the behavior of SAST and Secret Detection analyzers to their organization’s preferences.
> To improve this capability, we're introducing the ability to add rules from multiple sources, like Git repositories, local files, and raw source changes. This change makes it easier to synthesize and manage multiple custom rulesets from different locations, which organizations can use to inherit rules across repositories and sources for greater flexibility. We showcase the new features in [this blog post](/blog/2021/12/21/rule-pack-synthesis/).
> Initially, this change is available for our [SAST Semgrep, Nodejs, and Gosec analyzers](https://docs.gitlab.com/ee/user/application_security/sast/#customize-rulesets) and [Secret Detection](https://docs.gitlab.com/ee/user/application_security/secret_detection/#custom-rulesets). We will expand this capability to our other analyzers [in future releases](https://gitlab.com/groups/gitlab-org/-/epics/4179).
SAST, Secret Detection[Support HTTPS proxy settings of RetireJS](https://docs.gitlab.com/ee/user/application_security/dependency_scanning/#available-cicd-variables):
> Thanks to community contributor Ankur Sethi and their patience, Dependency Scanning now supports proxy settings in Retire.js by respecting the `HTTPS_PROXY` environment variable. If `HTTPS_PROXY` is set, it will be passed to the `retire` command line as a CLI option. Thank you!
Dependency Scanning[Customize deduplication of container scanning vulnerabilities](https://docs.gitlab.com/ee/user/application_security/container_scanning/#setting-the-default-branch-image):
> When scanning images, container scanning by default assumes that the image naming convention stores any branch-specific identifiers in the image tag rather than the image name. For customers who follow a naming convention where the branch name is part of the image name, this default setting makes the scanner unable to properly deduplicate identical vulnerabilities. You can now customize the default setting by specifying a new `CS_DEFAULT_BRANCH_IMAGE` variable in the container scanning job. This variable is set by default for projects that use Auto DevOps. This allows security checks in merge requests to properly identify new vs. pre-existing vulnerabilities, by de-duplicating any vulnerabilities that already exist in the default branch.
Container Scanning[SAST scan execution policies](https://docs.gitlab.com/ee/user/application_security/policies/#scan-action-type):
> Users can now require SAST 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 separately manage these scan requirements without allowing developers to change the configuration. You can get started with [security policies](https://docs.gitlab.com/ee/user/application_security/policies/#security-policies-project) on the **Security & Compliance > Policies** page. To specify SAST scans, set the `scan` field to `sast`.
Security Orchestration[Container Scanning results in the Dependency List](https://docs.gitlab.com/ee/user/application_security/container_scanning/#dependency-list):
> Security teams, compliance teams, and developers must have a complete picture of all dependencies used by a project. Container Scanning jobs now add any identified system dependencies to the dependency list by default. This list of system dependencies appears together with any application dependencies identified by a Dependency Scanning job. Users can now view this complete list of project dependencies in one centralized location on the **Security & Compliance > Dependency List** page.
Container Scanning[Unlink security policy projects](https://docs.gitlab.com/ee/user/application_security/policies/#unlink-security-policy-projects):
> Project owners can now unlink security policy projects from development projects. To do this, first navigate to **Security & Compliance > Policies** and select the **Edit Policy Project** button. Then select the trash can icon to unlink a previously-associated security policy project.
Security Orchestration[Geo verifies four additional data types](https://docs.gitlab.com/ee/administration/geo/replication/datatypes.html#data-types) (self-managed only):
> GitLab stores data such as [uploads](https://docs.gitlab.com/ee/administration/uploads.html), [LFS objects](https://docs.gitlab.com/ee/topics/git/lfs/), [Pages deployments](https://docs.gitlab.com/ee/user/project/pages/), and [external merge request diffs](https://docs.gitlab.com/ee/administration/merge_request_diffs.html#using-external-storage) in the file system or object storage. Geo replicates these data to one or many secondary sites, either to improve the productivity of distributed teams or as part of a disaster recovery strategy.
> Geo now also automatically verifies the data integrity of replicated uploads, LFS objects, Pages deployments, and external MR diffs when stored in the file system. This ensures that they are not corrupted in transfer or at rest. If you're using Geo as part of a disaster recovery strategy, this provides additional protection against data loss.
Disaster Recovery, Geo-replication[Seamless worldwide performance with Geo](https://docs.gitlab.com/ee/administration/geo/secondary_proxy) (self-managed only):
> Organizations with geographically distributed teams use Geo to provide a fast and efficient experience across the globe. Before GitLab 14.6, you could set up [Geo with a single, unified URL for all Git operations](https://docs.gitlab.com/ee/administration/geo/replication/location_aware_git_url.html). However, Geo replicas each had their own URL for web UI and API access, so users had to know the URL to the specific Geo replicas they wanted to use. The web UI of the Geo replicas was also read-only, limiting users to viewing pages and requiring them to perform changes on the primary site.
>
> In GitLab 14.6, Geo secondary sites transparently proxy write requests to the primary site while accelerating most read requests. Systems administrators can provide all GitLab users across their organization with a single URL that automatically uses the Geo site closest to them. Users no longer need to use different configuration to benefit from Geo, or worry about what operations won't work on Geo secondary sites. Globally distributed teams now benefit from accelerated `git clone` or `git pull` commands, and a seamless worldwide experience.
>
> Secondary proxying and unified URL support is enabled by default for new Geo installations. You can also [set up a unified URL](https://docs.gitlab.com/ee/administration/geo/secondary_proxy/index.html#set-up-a-unified-url-for-geo-sites) on an existing Geo installation and enable secondary proxying.
Geo-replication[GitLab Agent's activity information](https://docs.gitlab.com/ee/user/clusters/agent/install/#view-agent-activity-information):
> Being able to monitor your cluster's activity helps you detect and troubleshoot faulty events, and rest assured when they succeed.
>
> GitLab now ships with an activity list for the GitLab Agent that logs real-time events. This first implementation logs connection and token statuses and will be followed with more events in future releases.
> We also plan to provide a similar solution to [track CI/CD Tunnel events](https://gitlab.com/gitlab-org/gitlab/-/issues/340484), for which your early feedback is more than welcome.
Kubernetes Management[GitLab chart improvements](https://docs.gitlab.com/charts) (self-managed only):
> - In GitLab 14.6, the bundled [NGINX Ingress Controller has been upgraded to `v1.0.4`](https://docs.gitlab.com/charts/charts/nginx/index.html). GitLab is working towards support for Kubernetes 1.22 and a requirement of that is `v1.0.0` or higher of nginx-ingress.
> - For users using the in-chart NGINX Ingress Controller, the [new minimum version of Kubernetes is 1.19](https://docs.gitlab.com/charts/installation/#requirements). This is a requirement towards GitLab supporting Kubernetes 1.22.
Cloud Native Installation[Omnibus improvements](https://docs.gitlab.com/omnibus) (self-managed only):
> - GitLab 14.6 includes [Mattermost 6.1](https://mattermost.com/blog/mattermost-v6-1-is-now-available/), whose newest release includes a single view of recent mentions and saved posts across your teams, quick access to recently used reactions, timed do not disturb, Playbooks and Boards previews, Playbooks and Boards improved notifications and Boards calculations. This version also includes [security updates](https://mattermost.com/security-updates/) and upgrade from earlier versions is recommended.
> - GitLab 14.6 ships with packages for [Debian 11 Bullseye](https://www.debian.org/News/2021/20210814) for both amd64 and arm64 architectures.
Omnibus Package[Lighter stroke-width for icons](https://about.gitlab.com/blog/2021/12/17/hey-icons-lighten-up/):
> Product icons in GitLab have been updated to:
>
> - Be more balanced with other UI elements.
> - Better align with the brand.
> - Be constructed to be more future-proof by allowing easier iteration and introduction of new icons.
> - Work well in both light and dark UI.
> - Better convey abstract concepts and metaphors.
>
> For more details, see this [blog post](/blog/2021/12/17/hey-icons-lighten-up/) by [Staff Product Designer, Jeremy Elder](https://gitlab.com/jeldergl).
Design System[Private contributions visible in the contribution calendar graph](https://docs.gitlab.com/ee/user/profile/#show-private-contributions-on-your-user-profile-page):
> In this release, we changed how the contribution calendar graph in the user profile shows contributions. Private contributions were shown in the contribution list but not in the contribution calendar graph, which meant the user profile didn't fully represent user contributions. Thanks to [Dustin Eckhardt](https://gitlab.com/eggerd)'s contribution, private contributions now appear in the contribution calendar graph.
Users[WebAuthn enabled by default](https://docs.gitlab.com/ee/user/profile/account/two_factor_authentication.html#webauthn-device):
> WebAuthn (supported, but disabled by default, since GitLab 13.4) is now enabled by default. Users can now use Touch
> ID on Apple devices as a second authentication factor, as long as their browser supports it. This also eliminates
> error messages seen in browsers that are deprecating U2F in favor of WebAuthn.
Authentication and Authorization[Use the API to transfer a group to a parent group](https://docs.gitlab.com/ee/api/groups.html#transfer-a-group-to-a-new-parent-group--turn-a-subgroup-to-a-top-level-group):
> In this release we've added the ability for you to transfer a group to a new parent group with the Groups API. Previously, this was only possible through the UI.
>
> You can now use the Groups API to move subgroups to a different parent group and make a subgroup into a top-level group.
>
> This new functionality is available to administrators and users with:
>
> - Owner role for the group to transfer.
> - Permission to create a subgroup in the new parent group if transferring a group.
> - Permission to create a top-level group if turning a subgroup into a top-level group.
Subgroups[Auto deletion of old deployment git references](https://docs.gitlab.com/ee/ci/environments/#archive-old-deployments):
> As projects continue to be deployed, the number of deployments can increase substantially. To maintain high performance for Git commands, we have added automated deleting of [Git references](https://git-scm.com/book/en/v2/Git-Internals-Git-References) for old [deployments](https://docs.gitlab.com/ee/ci/environments/#check-out-deployments-locally). GitLab will keep the recent 50,000 deployments per project and automatically delete the Git references for the others.
Release Orchestration[Copy code blocks in Markdown with a single click](https://docs.gitlab.com/ee/user/markdown.html#code-spans-and-blocks):
> Instead of selecting all the code within a block and using your keyboard to copy it to your clipboard, you can now copy code blocks in Markdown with a single click.
Team Planning[Render the title of a referenced issue within markdown](https://docs.gitlab.com/ee/user/markdown.html#show-the-issue-merge-request-or-epic-title-in-the-reference):
> When referencing issues, epics, or merge requests within markdown fields, there was previously no way to surface and display additional context other than the ID. You can now append `+` to an issue, epic, or merge request reference to render the title.
Team Planning[Toggle wiki editors seamlessly](https://docs.gitlab.com/ee/user/project/wiki/#content-editor):
> Editing wiki pages with the new rich Markdown editor makes it easier for everyone to contribute regardless of how well they know Markdown syntax. You may also prefer to write raw Markdown in some situations, but use the WYSIWYG interface for more complex or tedious formatting tasks, like creating tables.
>
> Previous versions of GitLab required you to save changes before switching between the rich Markdown editor and the Markdown source, adding more steps and friction to your edits. In GitLab 14.6 you can now seamlessly switch between the two editing experiences without committing your changes, choosing the editor that suits your needs at any given moment.
>
> Note: This feature is defaulted to `off` for self-managed instances. To turn it on, enable the `wiki_switch_between_content_editor_raw_markdown` feature flag. In GitLab 14.8, self-managed instances will have this feature flag enabled by default.
Wiki[View inline the change that outdated a merge request thread](https://docs.gitlab.com/ee/user/discussions/):
> When addressing review feedback in merge requests, you often change lines your reviewers have commented on. In those comment threads, GitLab indicates that new changes were made. However, to understand if those new changes address the feedback, reviewers would have to navigate away from the context of the discussion.
>
> Now, when viewing threads related to old changes, you can view the new changes directly in the thread. This improved context helps you review faster and more accurately.
Code Review[Squash commit message template](https://docs.gitlab.com/ee/user/project/merge_requests/commit_templates.html):
> Squashing commits is a great way to clean up the commit history of a merge request by combining all commits when merging. Branch history becomes easier to read and follow, while the story behind the changes remains intact. GitLab previously used the merge request title as the default squash commit message. If you didn't edit the message before merging, important details about the change could be lost.
>
> Project maintainers can now customize the default squash commit message according to the project needs. Include details about each merge request, like the source and target branches, with helpful variables. With more complete squash commit messages, everyone can now better understand the context of the changes.
>
> Thanks to [Piotr](https://gitlab.com/trakos) for this amazing contribution!
Code Review[Support `job:when` and `rules` at the same time in CI/CD configuration](https://docs.gitlab.com/ee/ci/yaml/#rulesif):
> Previously, it was impossible to configure a GitLab CI/CD job to have both the [`rules`](https://docs.gitlab.com/ee/ci/yaml/#rules) and [`when`](https://docs.gitlab.com/ee/ci/yaml/#when) keywords defined at the job level. You had to add the `when` inside every `rules` section, which could cause long or repeated CI/CD configuration.
>
> In this release we've dropped that limitation and you can now use `when` at the job level along with `rules`. This makes `when` more flexible, and helps create job configurations that are much simpler.
Pipeline Authoring[Job failure reason returned in API response](https://docs.gitlab.com/ee/api/jobs.html):
> It can be hard to use the API to gather data about why a job failed. For example, you might want exact failure reasons to make better use of the [`retry:when`](https://docs.gitlab.com/ee/ci/yaml/#retrywhen) keyword.
>
> Now, the `failure_reason` is exposed in responses from the Jobs API, and it is much easier to gather job failure data. Thanks to [@albert.vacacintora](https://gitlab.com/albertvaka) for this contribution!
Continuous Integration (CI)[GitLab Runner Pod Cleanup](https://gitlab.com/gitlab-org/ci-cd/gitlab-runner-pod-cleanup/-/blob/main/readme.md):
> If you have leftover Kubernetes Runner pods, you can now use [GitLab Runner Pod Cleanup](https://gitlab.com/gitlab-org/ci-cd/gitlab-runner-pod-cleanup) to clean them up. This open-source utility is installed in the Kubernetes cluster alongside the GitLab Runner Manager, and when configured, deletes orphaned runner pods in the cluster. This new utility reduces maintenance overhead when using the Kubernetes executor for GitLab Runner to execute your CI/CD jobs at scale.
GitLab Runner[GitLab Runner 14.6](https://docs.gitlab.com/runner):
> We’re also releasing GitLab Runner 14.6 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.
>
> #### What's new:
>
> - [Always include `idle` value in `gitlab_runner_jobs` Prometheus metric](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/25845)
>
> #### Bug Fixes:
>
> - [PWSH Executor fails to terminate on job failure](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/28440)
> - [Old Runner pods are never deleted](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/27702)
>
> The list of all changes is in the GitLab Runner [CHANGELOG](https://gitlab.com/gitlab-org/gitlab-runner/blob/14-6-stable/CHANGELOG.md).
GitLab Runner[Webhook triggered for pending jobs](https://docs.gitlab.com/ee/user/project/integrations/webhook_events.html#job-events)
> Previously, using job event webhooks for CI/CD monitoring was challenging because it was difficult to track the number of `pending` jobs that may exist within a project.
>
> Now the webhook triggers an event when a job state changes to `pending`, so you no longer need to implement workarounds or custom integrations to keep track of all job statuses.
[Use Deploy Tokens to download Composer dependencies](https://docs.gitlab.com/ee/user/packages/composer_repository/#install-a-composer-package):
> You can now use [deploy tokens](https://docs.gitlab.com/ee/user/project/deploy_tokens/index.html) to authenticate users who interact with the Composer repository. Previously, [personal access tokens](https://docs.gitlab.com/ee/user/profile/personal_access_tokens.html) and job tokens were used to authenticate users that published and downloaded composer dependencies from the GitLab Composer repository. These tokens are tied to a specific user. [Deploy tokens](https://docs.gitlab.com/ee/user/project/deploy_tokens/index.html) provide an authentication method that isn't tied to specific users, ensuring that your production workflows are even more efficient and secure.
Package Registry[Publish Conan packages with only `name` and `version`](https://docs.gitlab.com/ee/user/packages/conan_repository/#package-without-a-username-and-a-channel):
> You use the GitLab Conan repository to publish and share your C/C++ packages. When creating a Conan package, there are four fields to consider: `name`, `version`, `user`, and `channel`. These fields uniquely identify a package. The `user` and `channel` fields are optional in [Conan 2.0](https://docs.conan.io/en/latest/conan_v2.html), but GitLab required you to continue using them. Customizing your naming conventions to match the requirements in GitLab instead of the standards set by Conan is inefficient and impractical.
>
> We've updated the GitLab Conan repository to align with Conan. Now you can publish and download your Conan packages with or without the `user` and `channel` fields. This improvement helps you to be more efficient and makes it easier to find and validate packages in the user interface. This change is the first step in a broader set of [planned improvements](https://gitlab.com/groups/gitlab-org/-/epics/6816) to the Conan repository to help move the feature from Beta to GA.
Package Registry[Enable Dependency Proxy cleanup policies from the UI](https://docs.gitlab.com/ee/user/packages/dependency_proxy/#enable-cleanup-policies-from-within-gitlab):
> You can use the GitLab Dependency Proxy to proxy and cache container images from Docker Hub for faster, more reliable builds. Over time, your team may add many items to the cache, resulting 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 added cleanup policies for the Dependency Proxy. You can programmatically delete from the cache image tags that your team hasn't recently used. However, this feature required you to use [GraphQL](https://docs.gitlab.com/ee/api/graphql/reference/index.html#mutationupdatedependencyproxyimagettlgrouppolicy), which is inefficient if you don't use it regularly.
>
> Now you can enable an automatic time-to-live (TTL) policy for the Dependency Proxy from the user interface. Do this by navigating to your group's **Settings > Packages & Registries > Dependency Proxy** and enabling the setting to automatically clear items from the cache after 90 days.
Dependency Proxy[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.6. These updates bring additional coverage, bug fixes, and improvements.
>
> - Spotbugs updated to v2.28.11 - [MR](https://gitlab.com/gitlab-org/security-products/analyzers/spotbugs/-/merge_requests/119), [Changelog](https://gitlab.com/gitlab-org/security-products/analyzers/spotbugs/-/blob/master/CHANGELOG.md#v22811)
> - Updates Log4j library to patched version (v4.5.2). See [blog post for more information](https://about.gitlab.com/blog/2021/12/15/updates-and-actions-to-address-logj-in-gitlab/)
> - Fix custom CA cert support
> - PMD updated to v2.12.10 - [MR](https://gitlab.com/gitlab-org/security-products/analyzers/pmd-apex/-/merge_requests/75), [Changelog](https://gitlab.com/gitlab-org/security-products/analyzers/pmd-apex/-/blob/master/CHANGELOG.md#v21210)
> - Proactive removal of Log4j library. See [blog post for more information](https://about.gitlab.com/blog/2021/12/15/updates-and-actions-to-address-logj-in-gitlab/)
> - Semgrep updated to v0.76.2 - [MR](https://gitlab.com/gitlab-org/security-products/analyzers/semgrep/-/merge_requests/94), [Changelog](https://gitlab.com/gitlab-org/security-products/analyzers/semgrep/-/blob/main/CHANGELOG.md#v2160)
> - Gosec updated to v2.9.5 - [MR](https://gitlab.com/gitlab-org/security-products/analyzers/gosec/-/merge_requests/137), [Changelog](https://gitlab.com/gitlab-org/security-products/analyzers/gosec/-/blob/master/CHANGELOG.md#v345)
>
> 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 need to update your CI configurations. To remain on a specific version of any analyzer, you can [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 require you to manually bump your analyzer version in your CI template.
SAST, Secret Detection[SAST Support for .NET 6](https://docs.gitlab.com/ee/user/application_security/sast/analyzers):
> Microsoft's [release of .NET 6.0](https://devblogs.microsoft.com/dotnet/announcing-net-6/) is the next major release of .NET Core, which contains both massive performance gains and new compute options, and should enable simplified .NET code. We have updated our .NET SAST analyzer, [Security Code Scan](https://security-code-scan.github.io/), to support this new version, which is also now supported with [our SAST language detection](https://docs.gitlab.com/ee/user/application_security/sast/#supported-languages-and-frameworks), allowing GitLab SAST to automatically detect .NET 6 projects. This change was part of a community contribution by [@vasyl11](https://gitlab.com/vasyl11) at [Clay Solutions](https://my-clay.com/), who we thank for their efforts.
>
> Due to backwards compatibility concerns, if you want to leverage this new .NET 6 SAST scanning, you will need to update your `.gitlab-ci.yml` file to [pin to the new major version](https://docs.gitlab.com/ee/user/application_security/sast/#pinning-to-minor-image-version) of Security Code Scan. You can add this [code snippet](https://gitlab.com/-/snippets/2223915) to your `.gitlab-ci.yml` file to try these new scanning capabilities. In a future release, we will announce the upcoming deprecation and removal in GitLab 15.0 of any version of .NET before 3.0 for SAST scanning, due to its [end of Life and last support date status with Microsoft](https://endoflife.date/dotnet). In GitLab 15.0, we will promote this new version of Security Code Scan to run by default, which will enable .NET 5 and 6 SAST scanning without the need for the experimental flag.
SAST[Quick action to promote an issue to an incident](https://docs.gitlab.com/ee/user/project/quick_actions.html#issues-merge-requests-and-epics):
> After investing time and effort in an issue, sometimes participants realize that the problem is actually an incident. Leveraging the quick action `/promote_to_incident`, users can now promote an issue to an incident. All existing context (title, description, labels, assignees, comments, and more) remain a part of the incident when the issue is promoted.
Incident Management