##### [Verify](https://about.gitlab.com/stages-devops-lifecycle/verify/)
[GitLab Build Cloud for macOS beta](https://docs.gitlab.com/ee/ci/runners/build_cloud/macos_build_cloud.html) (SaaS only): GitLab Runner
> Today, Apple ecosystem developers on GitLab SaaS need to install, manage, and operate GitLab Runner on their own macOS systems to execute CI/CD workflows.
>
> Now, you can build applications on the new Build Cloud beta for macOS, a GitLab Runner-powered build platform integrated with GitLab SaaS CI/CD.
>
> Access to the beta is initially limited to approved customers and open source community program members. For details, check out [this blog post](https://docs.gitlab.com/ee/ci/pipelines/compute_minutes.html#additional-costs-on-gitlab-saas).
>
> You can always install [macOS Runner](https://docs.gitlab.com/runner/install/osx.html#installing) on any on-premise Apple environment, [MacStadium](https://about.gitlab.com/blog/2017/05/15/how-to-use-macstadium-and-gitlab-ci-to-build-your-macos-or-ios-projects/), or [AWS](https://aws.amazon.com/ec2/instance-types/mac/).
#### [Ultimate](https://about.gitlab.com/pricing/ultimate/)
[Track use of dependency scanning and fuzz testing](https://docs.gitlab.com/ee/user/group/devops_adoption): DevOps Reports
> Track which groups across your organization have enabled dependency scanning and fuzz testing. Previously, you could only track adoption of these GitLab features through the API.
>
> Now you can compare adoption across your groups from the DevOps Adoption table in the UI and sort the table to easily find which groups are using these security features.
##### [Application security testing](https://about.gitlab.com/stages-devops-lifecycle/application_security_testing/)
[Improved vulnerability tracking for GoSec, Semgrep, and Brakeman analyzers](https://docs.gitlab.com/ee/user/application_security/sast/analyzers): SAST
> Over the course of a project's life cycle, code is moved around. Refactoring, additions to the code base, removals, will all happen. Our current fingerprinting of findings is too coarse and results in a lot of duplicated findings over time as code is moved around. SAST and Secret Detection findings currently use [location within a file](https://gitlab.com/gitlab-org/security-products/analyzers/common/-/blob/master/issue/issue.go#L244-261) to declare where they exist within a codebase. Over time we lose the ability to track the movement of a finding as lines are added to, or removed from the file above the finding in question. This reality makes it hard to discern findings that are truly _new_, especially in the context of a merge request.
>
> We've developed a new vulnerability tracking algorithm that is more advanced and looks at the signature of a vulnerability rather than just its location. This new tracking improves the accuracy of identifying the same vulnerability that has moved locations due to code refactoring.
>
> We've now brought this new vulnerability tracking system to our GoSec (Go) analyzer, Semgrep (JavaScript, TypeScript, React, and Python), and Brakeman (Ruby and Ruby on Rails) analyzers. We will continue expanding coverage of this new vulnerability tracking system to other language analyzers in future releases.
#### [Premium](https://about.gitlab.com/pricing/premium/)
[New GitLab Agent for Kubernetes UI](https://docs.gitlab.com/ee/user/clusters/agent/): Kubernetes Management
> The GitLab Agent for Kubernetes allows a secure bi-directional connection between GitLab and any Kubernetes cluster.
> Until now, registering a new Kubernetes Agent required writing GraphQL queries.
>
> As of GitLab 14.2, GitLab ships with a user-friendly user interface and a registration form to help you get started with the Kubernetes Agent with ease.
[Export membership CSV report from top-level group](https://docs.gitlab.com/ee/user/group/#export-members-as-csv): Audit Reports
> You can now export a report that lists all members in a given group. This was already possible at the [instance level](https://docs.gitlab.com/ee/administration/admin_area.html#user-permission-export) and
> we are very excited to bring it to the top-level group!
>
> This report contains information such as users, email addresses, and permissions levels, all describing the users who have access to the group.
>
> This report allows you to quickly get visibility into who is in a group,
> and what type of access is possible for your groups
> and projects, enabling you to rapidly identify required
> updates. This is a great step toward bringing a similar,
> high-quality experience to our GitLab.com users, in what was
> previously only available on self-managed GitLab.
[Add compliance framework labels to group-level project list](https://docs.gitlab.com/ee/user/project/settings/#compliance-frameworks): Compliance Management
> Compliance framework labels are now shown on the group-level project list. This allows you to
> identify at a glance which projects have specific compliance frameworks applied.
[Assign compliance framework to project using GraphQL](https://docs.gitlab.com/ee/api/graphql/reference/index.html#mutationprojectsetcomplianceframework): Compliance Management
> You can now set a compliance framework for projects using the GraphQL API
> in addition to the [GitLab UI](https://docs.gitlab.com/ee/user/project/settings/index.html#compliance-frameworks).
> This makes it easy to do bulk updates to many projects at once and supports those who
> prefer to create and configure projects programmatically.
[Show selected label when filtering Jira issues](https://docs.gitlab.com/ee/integration/jira/issues.html#view-jira-issues): Integrations
> Users can now see which labels they used to filter their Jira issues list. This change improves usability by allowing users to have full context of the list they are viewing.
[Geo verifies replicated versioned snippets](https://docs.gitlab.com/ee/administration/geo/replication/datatypes.html#data-types) (self-managed only): Disaster Recovery, Geo-replication
> Geo automatically verifies the data integrity of replicated [versioned snippets](https://docs.gitlab.com/ee/user/snippets.html#versioned-snippets). This ensures that snippets are not corrupted in the transfer or at rest. If Geo is used as part of a disaster recovery strategy, this protects customers against data loss.
>
> In the next iteration, we will implement [automatic healing](https://gitlab.com/gitlab-org/gitlab/-/issues/301244) once a mismatch in verification is detected.
>
> [Geo's verification capabilities](https://docs.gitlab.com/ee/development/geo/framework.html#verification) are implemented generically in Geo's replication framework and we are planning to bring verification to [all other replicated data types](https://gitlab.com/groups/gitlab-org/-/epics/5286).
>
> **Note:** This feature was originally announced by mistake in the GitLab 13.11 release post. It was available behind a feature flag, but not enabled by default. In GitLab 14.2, we removed the feature flag and enabled versioned snippet verification.
[Automatic creation of configuration file for CI/CD Tunnel](https://docs.gitlab.com/ee/user/clusters/agent/ci_cd_tunnel.html)
> Until now, users of the GitLab Agent for Kubernetes CI/CD Tunnel had to add
> a corresponding `kubeconfig` configuration file to a CI/CD job manually. Creating the
> `kubeconfig` file required editing the CI/CD pipeline definition, a knowledge of the Agent
> ID, and an understanding of how a `kubeconfig` is structured. It also introduced
> boilerplate code into the CI/CD pipeline definition.
>
> GitLab now injects a `kubeconfig` file that contains all the available agent connections for
> the given project. A user only has to choose the right `kubecontext` to use.
##### [Plan](https://about.gitlab.com/stages-devops-lifecycle/plan/)
[Immediately delete projects scheduled for delayed deletion](https://docs.gitlab.com/ee/user/group/#enable-delayed-project-removal): Issue Tracking
> Delayed project removal protects your data by placing deleted projects in a read-only state so you can restore them. Until now, [delayed project deletion](https://docs.gitlab.com/ee/user/group/#enable-delayed-project-removal) has been disabled on GitLab.com because there has been no way to immediately delete a project when necessary.
>
> In this release, we've added an instance setting to enable delayed deletion by default for all new projects. You can also immediately permanently delete projects that are scheduled for delayed deletion without globally disabling the setting.
>
> Delayed project deletion is now enabled by default for new groups and projects created on GitLab.com, and group owners can disable it.
##### [Monitor](https://about.gitlab.com/stages-devops-lifecycle/monitor/)
[Email specific users in an escalation policy](https://docs.gitlab.com/ee/operations/incident_management/escalation_policies.html#select-the-responder-of-an-escalation-rule): Incident Management
> When creating the escalation policy for alerts, it's useful to email a specific user in addition to the on-call user. In this release, we added the ability for teams to define the user to contact, even if that user isn't part of the on-call rotation.
#### Core
[Create a GitLab branch from a Jira issue](https://docs.gitlab.com/ee/integration/jira/connect-app.html): Integrations
> Users of the [GitLab.com for Jira Cloud](https://marketplace.atlassian.com/apps/1221011/gitlab-com-for-jira-cloud) application can now create GitLab branches directly from a Jira issue's [development panel](https://support.atlassian.com/jira-software-cloud/docs/view-development-information-for-an-issue/). This enables developers to begin work on issues without having to switch tools and lose context.
[Group Migration achieves parity with group import/export](https://docs.gitlab.com/ee/user/group/import/): Importers
> The new [GitLab Migration](https://docs.gitlab.com/ee/user/group/import/) feature can now migrate an entire group with all its subgroups and related data. The data migrated includes everything contained in [group exports](https://docs.gitlab.com/ee/user/group/settings/import_export.html), making this a much easier way to migrate entire groups.
> The pre-existing group import/export is a two-step process that requires exporting a file and then importing it into another GitLab instance.
>
> Now, users can initiate a group migration with a single click. Migration also includes all the subgroups and their data, which previously required separate export and import processes for each subgroup.
[Hide all issues created by banned users](https://docs.gitlab.com/ee/administration/moderate_users.html#ban-and-unban-users) (self-managed only): Authentication and Authorization, Users
> In a previous release, we added a new [banned user](https://docs.gitlab.com/ee/administration/moderate_users.html#ban-and-unban-users) state. In this release, we now also hide all issues created by a banned user. This is extremely helpful in cases where a malicious user bombards GitLab instances with spam issues. These can now be hidden.
[Add pronunciation to GitLab profile page](https://docs.gitlab.com/ee/user/profile/#add-your-pronunciation): Users
> You can now add pronunciation to your user profile. In distributed teams where team members are from different countries, it can be difficult to determine how to say someone's name correctly. This will help others know how to pronounce your name.
[View projects that use custom integration settings](https://docs.gitlab.com/ee/administration/settings/project_integration_management.html#view-projects-that-override-the-default-settings): Integrations
> In this release, we are making the management of project integration configuration much easier! GitLab administrators can now see a list of projects that are not using the default integration configuration. This functionality helps administrators ensure that projects have the right data from integrated systems.
[Hide application secrets](https://docs.gitlab.com/ee/integration/oauth_provider.html) (self-managed only): Authentication and Authorization
> Previously, the **Secret** field was visible in the GitLab UI on an application's configuration page. To improve security, we have hidden this field from the UI and added a **Copy** button. You can then copy the secret and store it in a secured location. This makes sure the secret is not visible in clear text for anyone looking at the screen.
[Load balancing for Sidekiq enabled by default](https://docs.gitlab.com/ee/administration/database_load_balancing.html#load-balancing-for-sidekiq): Memory
> Sidekiq, the job scheduler used by GitLab, creates a number of read-only jobs. When using a database cluster that includes a read and writable primary node and one or many read-only nodes, these jobs do not have to be executed on the primary node. Instead, they can benefit from database load balancing and execute on read-only nodes. This reduces the overall load on the primary database node and can result in performance improvements.
>
> Sidekiq load balancing was introduced in GitLab 14.1 and is enabled by default in GitLab 14.2.
[GitLab chart improvements](https://docs.gitlab.com/charts) (self-managed only): Cloud Native Installation
> GitLab 14.2 also includes a reformatting of `global.imageXxYy` to `global.image.x`. This simplifies the different global image commands. For example:
>
> - `global.imagePullPolicy` becomes `global.image.pullPolicy`
> - `global.imagePullSecrets` becomes `global.image.pullSecrets`.
>
> This will continue to be improved with future iterations.
[Omnibus improvements](https://docs.gitlab.com/omnibus) (self-managed only): Omnibus Package
> - GitLab 14.2 includes [Mattermost 5.37](https://mattermost.com/blog/mattermost-v5-37/), an [open source Slack-alternative](https://mattermost.com/) whose newest release includes a new beta feature, [Collapsed Reply Threads](https://mattermost.com/blog/collapsed-reply-threads-beta/). Users may experience bugs, and [current known issues are documented](https://docs.mattermost.com/help/messaging/organizing-conversations.html#known-issues). Additionally v5.37 includes support for emoji standard v13.0. If you have added a custom emoji in the past that uses one of the new system names, then it is going to get overwritten by the system emoji. The workaround is to change the custom emoji name. Also, parts of Incident Collaboration are now available to all Mattermost editions. As part of this update, Incident Collaboration will require a minimum server version of v5.37.
> - GitLab 14.2 supports two new features for more secure Patroni patterns. This includes [support of TLS for the Patroni API](https://docs.gitlab.com/ee/administration/postgresql/replication_and_failover.html#enable-tls-support-for-the-patroni-api), allowing users to use TLS for a more secure communication. GitLab 14.2 also includes [support for `allowlist` and `allowlist_include_members`](https://gitlab.com/gitlab-org/omnibus-gitlab/-/issues/6260) with Patroni. This allows users to limit write access to the Patroni REST API by IP address, a further protection in addition to the authentication measures.
[Expose `deployment_tier` in the Pipeline events webhook](https://docs.gitlab.com/ee/user/project/integrations/webhooks.html#pipeline-events): Continuous Delivery
> In GitLab 13.10, we introduced the concept of [deployment tier](https://docs.gitlab.com/ee/ci/environments/#deployment-tier-of-environments). In this release, we added `deployment_tier` in the [Pipeline events webhook](https://docs.gitlab.com/ee/user/project/integrations/webhooks.html#pipeline-events) so that you can use it in your automations.
[Add file path copy ability to code search results](https://docs.gitlab.com/ee/user/search/advanced_search.html): Global Search
> Users often want to search for files and then open them in their editor of choice. In GitLab 14.2, we added a file path copy icon beside the file path of the search results. Users can click the icon to copy the file path and paste it to their editors to open the file.
[Display local time on user's profile](https://docs.gitlab.com/ee/user/profile/#access-your-user-profile): Users
> Local time is now displayed on user profiles. In previous releases, you could set the timezone but it was not visible throughout GitLab. This improvement is extremely helpful for distributed teams to help others know when others are likely to be available.
[See the number of items in each stage in project-level Value Stream Analytics](https://docs.gitlab.com/ee/user/analytics/value_stream_analytics.html): Value Stream Management
> You can now more easily see the volume of work in each stage. Value Stream Analytics for projects now shows the total number of workflow items in each stage of a value stream.
[View all Value Stream Analytics metrics for projects](https://docs.gitlab.com/ee/user/analytics/value_stream_analytics.html): Value Stream Management
> Until now, project and group-level metrics in value stream management displayed different data sets.
>
> In this release, you can view the same metrics on the project and group level, based on your GitLab subscription. Both project and group analytics now include **New Issues**, **Commits**, **Deploys**, **Deployment Frequency**, **Lead Time** (Premium and Ultimate), and **Cycle Time** (Premium and Ultimate).
[Group access tokens as Git credentials](https://docs.gitlab.com/ee/user/project/settings/project_access_tokens.html#group-access-token-workaround) (self-managed only): Authentication and Authorization
> Customers with Rails console access can create group access tokens to perform actions at the
> group level, and manage projects in the group with a single token. Previously, using a group
> access token for Git credentials caused an authentication failure. In this release, we've:
>
> - Added support for group access tokens to authenticate with Git over HTTP, making it
> possible to push and pull changes with a group token.
> - Also provided [instructions for creating group access tokens in a Rails console](https://docs.gitlab.com/ee/user/project/settings/project_access_tokens.html#group-access-token-workaround)
> for your convenience.
[View Terraform state parameters in the UI](https://docs.gitlab.com/ee/user/infrastructure/terraform_state.html#get-started-using-local-development): Infrastructure as Code
> The GitLab managed Terraform state can be accessed from GitLab
> CI/CD without any special configuration. To access the same state from a local
> machine, Terraform must be initialized with several parameters.
>
> Finding the right parameters can be a tedious and error-prone process, so we now provide a
> simple user interface on the Terraform State list page
> that shows the command to use to initialize a Terraform state access from the command
> line. You can access this view from the **Infrastructure > Terraform** menu.
[Timeout state search tips for Global Search Result page](https://docs.gitlab.com/ee/user/search/#basic-search): Global Search
> Sometimes when searching broadly across GitLab, timeouts can occur. We implemented a search timeout page to help users in these situations and take advantage of stronger search criteria.
##### [Plan](https://about.gitlab.com/stages-devops-lifecycle/plan/)
[Edit issue title from an issue board](https://docs.gitlab.com/ee/user/project/issue_board.html#edit-an-issue): Boards, Issue Tracking
> Editing an issue in an issue board currently requires many steps and takes you out of your workflow. We've added an easy way to edit an issue's title right in the issue board, without navigating to another page. To edit the title, in the right sidebar, select the issue, then select **Edit**.
##### [Create](https://about.gitlab.com/stages-devops-lifecycle/create/)
[Launch a preconfigured Gitpod workspace from a merge request](https://docs.gitlab.com/ee/integration/gitpod.html#launch-gitpod-in-gitlab): Live Preview, Web IDE, Code Review
> The Gitpod integration, introduced in GitLab 13.5, helps you manage your complicated development environments. Once you define your project's configuration in code, you can launch a prebuilt, cloud-based development environment with a single click. This convenient workflow has made it faster than ever to generate new changes, but launching a Gitpod environment to review an existing merge request meant building an environment against the main branch before switching to the target branch and building again.
>
> Now, in GitLab 14.2, you can launch Gitpod directly from the merge request page, preconfigured to use the target branch, to speed up your reviews and reduce the need for context switching. [Enable the Gitpod integration](https://docs.gitlab.com/ee/integration/gitpod.html#enable-gitpod-in-your-user-settings), and your merge requests display a grouped **Open in** button, so you can open the merge request in either the Web IDE or Gitpod.
>
> Thanks to [Cornelius Ludmann](https://gitlab.com/corneliusludmann) from [Gitpod](https://www.gitpod.io/) for this contribution!
[Preview Markdown live while editing](https://docs.gitlab.com/ee/user/project/web_ide/#markdown-editing): Web IDE
> Markdown is a fast and intuitive syntax for writing rich web content. Until it isn't. Luckily, it's easy to preview the rendered output of Markdown to ensure the accuracy of your markup from the **Preview** tab. Unfortunately, the context switch required to move between the raw source code and the preview can be tedious and disruptive to your flow.
>
> Now, in both the Web IDE and single file editor, Markdown files have a new live preview option available. Right-click the editor and select **Preview Markdown** or use `Command/Control + Shift + P` to toggle a split-screen live preview of your Markdown content. The preview refreshes as you type, so you can be confident that your markup is valid and will render as you intended.
[Format wiki pages more easily](https://docs.gitlab.com/ee/user/project/wiki/#use-the-content-editor): Wiki
> The new WYSIWYG editor has made writing Markdown in your wiki easier than ever. However, the toolbar's position in the editor made formatting text on longer pages tedious and repetitive.
>
> In GitLab 14.2, the most frequently used formatting options (bold, italic, strikethrough, and code) display in a floating menu above your text selection. By limiting the distance you have to move your cursor while formatting, you can work more efficiently. Spend more time focusing on your content, and less on scrolling up and down the page.
[Upload and attach files in the new wiki editor](https://docs.gitlab.com/ee/user/project/wiki/#use-the-content-editor): Wiki
> GitLab 14.1 introduced the ability to upload and insert images into the new wiki content editor.
>
> Now in GitLab 14.2, you can upload and attach `.zip`, `.pdf`, `.txt`, and other binary files in the same way. This brings us one step closer to feature parity with the classic wiki editor, and unlocks additional ways for you to collaborate on rich content in your wiki pages.
##### [Verify](https://about.gitlab.com/stages-devops-lifecycle/verify/)
[Use CI/CD variables in `include` statements in `.gitlab-ci.yml`](https://docs.gitlab.com/ee/ci/yaml/includes.html#use-variables-with-include): Pipeline Authoring
> You can now use variables as part of `include` statements in `.gitlab-ci.yml` files. These variables can
> be instance, group, or project CI/CD variables.
>
> This improvement provides you with more flexibility to define pipelines. You can copy the same `.gitlab-ci.yml` file to multiple projects and use variables to alter its behavior. This allows for less duplication in the `.gitlab-ci.yml` file and reduces the need for complicated per-project configuration.
[Stageless pipelines](https://docs.gitlab.com/ee/ci/yaml/#needs): Pipeline Authoring
> Using the [`needs`](https://docs.gitlab.com/ee/ci/yaml/#needs) keyword in your pipeline configuration helps to reduce cycle times by ignoring stage ordering and running jobs without waiting for others to complete. Previously, `needs` could only be used between jobs on different stages.
>
> In this release, we've removed this limitation so you can define a `needs` relationship between any job you want. As a result, you can now create a complete CI/CD pipeline without using stages by including `needs` in every job to implicitly configure the execution order. This lets you define a less verbose pipeline that takes less time to create and can run even faster.
[View historical CI pipeline minute usage](https://docs.gitlab.com/ee/subscriptions/gitlab_com/index.html#ci-pipeline-minutes): Continuous Integration (CI)
> Before GitLab 14.2, the CI pipeline minutes usage on the [Usage Quotas](https://docs.gitlab.com/ee/administration/settings/continuous_integration.html#shared-runners-pipeline-minutes-quota) page only showed the current month's usage. This data would reset every month and there was no way to view activity from the past months for analyzing historical usage.
>
> Now there are two charts that show historical CI pipeline minutes usage by month or by project, so you can make informed decisions about your pipeline usage.
[Show linked pipelines in the mini pipeline graph](https://docs.gitlab.com/ee/ci/pipelines/#visualize-pipelines): Pipeline Authoring
> The pipeline mini graph shows you the status of each stage in your pipeline and gives you a quick and easy way to navigate to any job. Linking multiple pipeline mini graphs together provides you with the same functionality for related upstream and downstream pipelines.
>
> In this release, you have the ability to see linked upstream and downstream pipelines in the mini graph in new areas in the GitLab UI: the pipeline tab, the project pipeline page, the commit page, and the commit page's pipeline tab.
[Show pipeline IID in the pipelines page](https://docs.gitlab.com/ee/ci/pipelines/#view-pipelines): Continuous Integration (CI)
> The pipeline IID gives the internal ID of a pipeline relative to the project that triggered it, and it increments for every new pipeline in the project. The pipeline IID increments much slower than the pipeline ID, which increments by one for every pipeline in the whole GitLab instance. This makes the pipeline IID a more useful value for use cases like versioning project releases based on pipelines, tracking pipelines based on their run order in the project, project pipeline metrics, etc.
>
> To help improve the experience of using the pipeline IID, we are adding an option to the pipelines page to change the display from the ID, to the internal project IID. Now you can easily see which pipeline matches the IIDs you are using.
[GitLab Runner 14.2](https://docs.gitlab.com/runner): GitLab Runner
> We’re also releasing GitLab Runner 14.2 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:
>
> - [Kubernetes `PreStop` lifecycle hook](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/3630).
> - [Support for Windows build pods in the Kubernetes executor](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/4014).
> - [In job output, create a section for each `.gitlab-ci.yml` script line when `FF_SCRIPT_SECTIONS` feature flag is enabled](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/4835).
> - [Allow CI image option to override base image name (VirtualBox & Parallels)](https://gitlab.com/gitlab-org/gitlab-runner/-/merge_requests/1257).
> - [Specified Git version upgraded to 2.30.2](https://gitlab.com/gitlab-org/gitlab-runner/-/merge_requests/2825).
>
> #### Bug fixes:
>
> - [Invalid UTF-8 results in 500 error on pipeline and job page](https://gitlab.com/gitlab-org/gitlab/-/issues/336356).
> - [Unable to clean removed sub-submodules when using `GIT_STRATEGY: fetch`](https://gitlab.com/gitlab-org/gitlab/-/issues/331042).
> - [Fix Ubuntu helper image builds to use correct platform (not always `amd64`)](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/28069).
>
> The list of all changes is in the GitLab Runner [changelog](https://gitlab.com/gitlab-org/gitlab-runner/blob/v14.2.0/CHANGELOG.md).
##### [Package](https://about.gitlab.com/stages-devops-lifecycle/package/)
[Share your container registry without sharing source code](https://docs.gitlab.com/ee/user/packages/container_registry/#container-registry-visibility-permissions): Container Registry
> When you are configuring your project, you can control feature-specific permissions for things like issues or the repository. For example, in a public project, you can still limit repository access to project members only.
>
> The problem is that although you can control several features like this, for the container registry, you only had the ability to toggle the feature on and off. This is problematic for many organizations that would like to control access to the container registry separately from the repository.
>
> Now you can avoid that problem by configuring your project to define an access level for your container registry independent of the access level of your repository and other features. You can do this using the project’s API and the user interface.
[Use deploy tokens with the Dependency Proxy](https://docs.gitlab.com/ee/user/packages/dependency_proxy/#authenticate-with-the-dependency-proxy): Dependency Proxy
> To reduce your reliance on external dependencies and reduce build times, you can use the GitLab Dependency Proxy to cache frequently used images from [Docker Hub](https://hub.docker.com/).
>
> You can now use deploy tokens when authenticating to use the GitLab Dependency Proxy. Previously, you had to authenticate with [predefined environment variables](https://docs.gitlab.com/ee/user/packages/dependency_proxy/#authenticate-within-cicd). Such variables are tied to a user's permissions and therefore not ideal for production pipelines. Deploy tokens are easier to manage for authentication. With deploy tokens, you don't have to worry about adding someone to your project. You can create a token, set the desired scope, and then rotate users according to your organization's policies.
>
> Simply create a group deploy token and user name with the scope set to `read_registry` and `write_registry`. Then you can login to the GitLab.com registry with your deploy token `username` and `password`, and proxy and cache container images from Docker Hub.
##### [Application security testing](https://about.gitlab.com/stages-devops-lifecycle/application_security_testing/)
[Improved usability of Security & Compliance Configuration page](https://docs.gitlab.com/ee/user/application_security/configuration/): Vulnerability Management
> GitLab has greatly expanded Security and Compliance functionality
> over the last year. As features have grown, so have the number of related configuration
> options. The current Security & Compliance Configuration page has expanded beyond
> what it was originally designed to accommodate, making finding the right option
> cumbersome.
>
> To address this, we have redesigned the Security & Compliance
> Configuration page. Not only does the new design improve usability, it provides a
> flexible pattern that will scale as we continue to add to our security and compliance
> offerings.
[SAST Go analyzer updated to support Go 1.16](https://docs.gitlab.com/ee/user/application_security/sast/analyzers): SAST
> We have updated our Static Application Security Testing (SAST) Go analyzer, GoSec, to support Go 1.16. This update introduces support for Go projects requiring this version of Go but also limits `GOPATH` shimming to only projects without Go modules.
> Should you require `GOPATH` shimming 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) using [GoSec version 3.1.3](https://gitlab.com/gitlab-org/security-products/analyzers/gosec/-/tags/v3.1.3). Pinning to a previous version will prevent you from receiving automatic analyzer updates and require you to manually bump your analyzer version in your CI template.
[Static Analysis analyzer updates](https://docs.gitlab.com/ee/user/application_security/sast/analyzers): SAST, Secret Detection
> 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.2. These updates bring additional coverage, bug fixes, and improvements.
>
> - GoSec updated to version 2.8.1 - [MR](https://gitlab.com/gitlab-org/security-products/analyzers/gosec/-/merge_requests/119), [Changelog](https://gitlab.com/gitlab-org/security-products/analyzers/gosec/-/tags/v3.1.3).
> Please see [update notice for support for 1.16](#sast-go-analyzer-updated-to-support-go-116).
> - Security Code Scan updated to version 5.2.1 - [MR](https://gitlab.com/gitlab-org/security-products/analyzers/security-code-scan/-/merge_requests/80/), [Changelog](https://gitlab.com/gitlab-org/security-products/analyzers/security-code-scan/-/tags).
> Please see [update notice for major version](#sast-net-analyzer-updated-to-support-visual-studio-2019-projectss).
> - ESLint updated to version 7.32.0 - [MR](https://gitlab.com/gitlab-org/security-products/analyzers/eslint/-/merge_requests/87), [Changelog](https://gitlab.com/gitlab-org/security-products/analyzers/eslint/-/tags/v2.22.0).
> - Semgrep updated to version 0.60.0 - [MR](https://gitlab.com/gitlab-org/security-products/analyzers/semgrep/-/merge_requests/72), [Changelog](https://gitlab.com/gitlab-org/security-products/analyzers/semgrep/-/tags/v2.9.4).
>
> If you:
>
> - Are [including 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/CD template, you will need to update your CI/CD configurations.
> - 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 will prevent you from receiving automatic analyzer updates and require you to manually bump your analyzer version in your CI/CD template.
[SAST .NET analyzer updated to support Visual Studio 2019 projects](https://docs.gitlab.com/ee/user/application_security/sast/analyzers): SAST
> We have updated our Static Application Security Testing (SAST) for .NET, Security Code Scan, to [migrate to a new Alpine base image](https://gitlab.com/gitlab-org/security-products/analyzers/security-code-scan/-/merge_requests/84/diffs) for this analyzer for consistency as well as improved stability, performance, and security. This generally should not cause problems, however if you leverage `before_script` with the [`security-code-scan-sast` job](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Jobs/SAST.gitlab-ci.yml#L219), you may need to update your `before_script` to resolve any incompatible function calls.
>
> We've also updated Security Code Scan to its latest major version ([v5](https://github.com/security-code-scan/security-code-scan/releases)). This adds support for projects built with Visual Studio 2019 and is a major upgrade to a new inter-procedural taint analysis engine. Due to the major upgrade, we are making this opt-in for now and a future release will update this version by default. To begin using this updated version, please leverage the following [override to pin Security Code Scan to the new version](https://docs.gitlab.com/ee/user/application_security/sast/#pinning-to-minor-image-version): `SAST_ANALYZER_IMAGE_TAG: 3`.
>
> In future versions of GitLab, we will update the default version of Security Code Scan to this new version, at which point you will no longer need to use the above code snippet.
[Semgrep SAST Analyzer for C](https://docs.gitlab.com/ee/user/application_security/sast/#supported-languages-and-frameworks): SAST
> 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 C language.
> [Developed in partnership](https://about.gitlab.com/releases/2021/04/22/gitlab-13-11-released/#gitlab--semgrep-upgrading-sast-for-the-future) with [r2c](https://r2c.dev/), the team behind Semgrep who share our mission to help developers write more secure code. After an extensive beta with hundreds of customers trying out our [experimental analyzer](https://docs.gitlab.com/ee/user/application_security/sast/#experimental-features), we're ready to start the transition to Semgrep.
> With 14.2, we're updating our managed 'SAST.gitlab-ci.yml' CI template to automatically run this new analyzer alongside our existing C/C++ analyzer, [Flawfinder](https://gitlab.com/gitlab-org/security-products/analyzers/flawfinder/). In a future release, we will fully disable Flawfinder once we add support for C++, 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 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.
##### [Monitor](https://about.gitlab.com/stages-devops-lifecycle/monitor/)
[Add quick action for updating incident severity](https://docs.gitlab.com/ee/operations/incident_management/manage_incidents.html#change-severity): Incident Management
> You can now update the incident issue's severity with the `/severity` quick action. For example, using the `/severity 3` quick action in an incident issue sets the severity to 3. This handy keyboard shortcut enables incident responders to quickly update the incident and get right back to resolving the problem.