GitLab.org/GitLab: Release v14.5.0-ee
Name: GitLab
Owner: GitLab.org
Release: GitLab 14.5
Released: 2021-11-22
License: MIT
Release Assets:
[Audit events for group SAML configuration changes](https://docs.gitlab.com/ee/administration/audit_events.html#group-events) (SaaS only):
> GitLab now records audit events for changes to additional group SAML settings. Events are created when changes are made to:
>
> - Enabled status
> - Enforcing SSO-only authentication for web activity
> - Enforcing SSO-only authentication for Git and Dependency Proxy activity
> - Enforcing users to have dedicated group-managed accounts
> - Prohibiting outer forks
> - Identity provider SSO URL
> - Certificate fingerprint
> - Default membership role
> - SSO-SAML group sync configuration
>
> These events give you visibility on who configured or changed group SAML settings, and when. They can be used in
> an audit to show that controls were correctly set and then never changed, or they can identify any changes that were
> made that need to be further examined.
Audit Events, Authentication and Authorization[Include Minimal Access role in SAML Group Sync](https://docs.gitlab.com/ee/user/group/saml_sso/#group-sync) (SaaS only):
> Administrators can now specify SAML Group Links with a minimal access role only for the top-level groups. This allows administrators to enhance security by defaulting to minimal access when the user is provisioned and assign more permissive roles at the sub-group level.
Authentication and Authorization[Fine-tune vulnerability check rules](https://docs.gitlab.com/ee/user/application_security/#enable-the-vulnerability-check-rule):
> When defining vulnerability check rules, users need a high degree of granularity so they can tailor the rules to only trigger MR approval when it is required per their organization's security policies. GitLab now supports more granular vulnerability check rules. Users can now define which scanners, severity levels, and vulnerability types are considered when triggering a rule. Additionally, users can set a minimum threshold for the number of vulnerabilities that must meet the criteria before the MR requires approval. By only requiring vulnerability check approvals on MRs that truly need it, this increased granularity allows teams to free up developers and security teams. You can configure these granular vulnerability checks by navigating to the **Settings > General > Merge request approvals** page in your project.
Security Orchestration[Fine grained permissions control with the CI/CD tunnel](https://docs.gitlab.com/ee/user/clusters/agent/repository.html#use-impersonation-to-restrict-project-and-group-access):
> Keeping your clusters' access safe is paramount for most companies. The CI/CD Tunnel for the GitLab Agent for Kubernetes enables secure access to the cluster from within GitLab CI/CD. Until now, the Tunnel inherited all the permissions of the service account of the installed agent in the cluster. Many users need stricter permission controls, preferably at the user or job level.
>
> In GitLab 14.5, we are pleased to release a generic access impersonation and a CI/CD job impersonation. These impersonations can be specified in the Agent configuration file, and the impersonated account permissions can be managed using Kubernetes RBAC rules.
Kubernetes Management[Geo provides a single command to promote a secondary node](https://docs.gitlab.com/ee/administration/geo/disaster_recovery/planned_failover.html) (self-managed only):
> When performing a failover, systems administrators use different tools depending on the underlying architecture. On a single-node Geo site, administrators can use the `gitlab-ctl promote-to-primary-node` command. However, multi-node sites did not support this command and required manual editing of configuration. This was cumbersome for large environments because it required updating dozens of configuration files.
>
> Now, administrators can use `gitlab-ctl geo promote` on any node of a Geo secondary site to promote it to a primary. In a disaster recovery scenario or planned failover, this saves precious time and reduces potential errors when promoting a secondary site to a primary. This command also makes it easier to script the failover process.
>
> As of GitLab 14.5, the commands `gitlab-ctl promote-to-primary-node` and `gitlab-ctl promote-db` are deprecated and will be removed in GitLab 15.0.
Disaster Recovery[Group-level settings for merge request approvals](https://docs.gitlab.com/ee/user/group/#group-approval-rules):
> You can now define and enforce values for merge request approval settings at the group level.
> These values cascade and are used by any projects within the group.
>
> Group-level merge request approvals make it easy for organizations to ensure proper separation of duties across all teams. You only have to
> specify settings in a single location now, rather than needing to update and monitor every project. When set at the group level, you:
>
> - Can be confident that projects will use consistent separation of duties workflows.
> - Do not need to manually check that every project has not had its settings modified.
Compliance Management[Allow updates to attributes for SAML or SCIM users](https://docs.gitlab.com/ee/user/group/saml_sso/#configure-user-settings-from-saml-response):
> In previous versions of GitLab, we supported the `project_limit` and `can_create_groups` attributes only on newly SAML provisioned users. If users were created using SCIM or is updated in the SAML provider with these attributes, the `project_limit` and `can_create_groups` values would not be updated.
>
> Now, if a user is created using SCIM or has an update to these attributes in the SAML provider, these sync to GitLab. This allows the identity provider to act as the single source of truth for core user attributes.
Authentication and Authorization[Return alert ID in POST responses for alerts](https://docs.gitlab.com/ee/operations/incident_management/integrations.html#response-body):
> Currently, when you POST an alert using the generic alert HTTP Endpoint the response is a simple 200 upon a successful POST. If you want to reconcile your current alert workflows, you may need to see additional information returned in the POST response. In this release, we added the alert ID (`iid`) to the response, enabling you to see your specific alerts by a unique ID.
Incident Management[GitLab Agent for Kubernetes available in GitLab Free](https://docs.gitlab.com/ee/user/clusters/agent/):
> Connecting a Kubernetes cluster with the GitLab Agent for Kubernetes simplifies the setup for cluster applications and enables secure GitOps deployments to the cluster. Initially, the GitLab Agent for Kubernetes was available only for Premium users. In our commitment to the open-source ethos, we moved the core features of the GitLab Agent for Kubernetes and the CI/CD Tunnel to GitLab Free. We expect that the open-sourced features are compelling to many users without dedicated infrastructure teams and strong requirements around cluster management. Advanced features remain available as part of the GitLab Premium offering.
Kubernetes Management[Explore project topics tab](https://docs.gitlab.com/ee/user/project/working_with_projects.html#explore-topics):
> In this release, thanks to [Jonas Wälter's](https://gitlab.com/wwwjon) contributions, we've added a new **Explore topics** tab in **Projects**.
>
> - Topics are sorted by popularity (the number of projects with this topic).
> - Topics can be searched by name and are then sorted by similarity and by popularity.
>
> When you select a topic, you can view its description and avatar, and all of its corresponding projects.
Projects[Topic management in the Admin Area](https://docs.gitlab.com/ee/administration/admin_area.html#administering-topics) (self-managed only):
> In this release, thanks to [Jonas Wälter's](https://gitlab.com/wwwjon) contributions, we've introduced several features for administrators to manage project topics in the Admin Area:
>
> - Add and edit project topics.
> - Search topics based on any string.
> - Add avatars and descriptions to topics (supports Markdown).
Projects[Conditional includes with `exists` keyword](https://docs.gitlab.com/ee/ci/yaml/includes.html#use-rules-with-include):
> The `include` keyword is one of the most popular ones to use when writing a full CI/CD pipeline. If you are building larger pipelines, you
> are probably using the `include` keyword to bring external YAML configuration into your pipeline.
>
> In this release, we are expanding the power of the keyword so you can use include with `exists` in the rules condition. Now, you
> can decide when external CI/CD configuration should or shouldn’t be included based on when certain files exist in the repository.
Pipeline Authoring[Add personal README to profile](https://docs.gitlab.com/ee/user/profile/#add-details-to-your-profile-with-a-readme):
> You can now add a README section to your GitLab profile! This is a great way to tell
> others about, your interests, how you work,
> or anything else you want!
>
> To add a README section, create a new public project with the same name as your user account and add a new
> [README file](https://docs.gitlab.com/ee/user/project/repository/index.html#readme-and-index-files). The contents
> of that file are automatically shown on your GitLab profile.
Authentication and Authorization[CI/CD Tunnel support for Omnibus installations](https://docs.gitlab.com/ee/user/clusters/agent/ci_cd_tunnel.html) (self-managed only):
> The CI/CD Tunnel support for self-managed instances installed through GitLab Charts was introduced in 14.0 and significantly improved since then. In this release, we are adding support for Omnibus installations.
>
> The CI/CD Tunnel provides a secure connection from within GitLab CI/CD to your Kubernetes clusters using the GitLab Agent for Kubernetes. This enables users to continue using their existing tools and processes, and adopt the Agent for a robust and safe setup.
Kubernetes Management[GitLab chart improvements](https://docs.gitlab.com/charts) (self-managed only):
> In GitLab 14.5, we now support the ability to [set the Ingress API version via Helm values](https://docs.gitlab.com/charts/charts/globals.html#configure-ingress-settings). This ability supports our work towards Kubernetes 1.22. When Kubernetes 1.22 is fully supported, when a user installs our Chart on a 1.22 cluster, a newer supported version on Ingress is be chosen. Users can manually specify the newer supported version if not installing against a live cluster, like when running a helm template.
Cloud Native Installation[Omnibus improvements](https://docs.gitlab.com/omnibus) (self-managed only):
> - With CentOS 8 EOL approaching, we have added support for AlmaLinux as a replacement in GitLab 14.5. AlmaLinux is backed by a company with a long track record of building an enterprise Linux compatible distribution and has the processes in place to sustain it. This aligns to our preference for the boring solution.
> - GitLab will now publish an ARM64 version of GitLab Enteprise Edition to the AWS Community AMI catalog. AWS is seeing a rise in adoption of AWS Graviton2 (ARM64), so we want to make sure GitLab EE will be usable for those users accessing the AWS Community AMI catalog. This documentation contains relevant information for using the [AWS community AMIs](https://docs.gitlab.com/ee/install/aws/manual_install_aws.html#find-official-gitlab-created-ami-ids-on-aws).
> - GitLab 14.5 will [provide packages for openSUSE Leap 15.3](https://gitlab.com/gitlab-org/omnibus-gitlab/-/issues/6426). OpenSUSE Leap 15.2 will reach its end of life on December 31st, 2021, therefore we want to provide OpenSUSE 15.3 in advance so users have a few milestones to make the move to a more recent version of OpenSUSE.
Omnibus Package[Manage project topics with the API](https://docs.gitlab.com/ee/api/topics):
> In this release, thanks to [Jonas Wälter's](https://gitlab.com/wwwjon) contributions, adding topics in project settings is easier than ever. In addition to the latest project topic management features in the UI, you can now use the API to retrieve topics by list or ID. We've also made it possible for administrators to create or edit topics through the API. This introduces full parity between project topic management in the UI and API.
Projects[Automatically unblock LDAP users when signing in with other providers (SAML, OAuth, OmniAuth)](https://docs.gitlab.com/ee/administration/auth/ldap/index.html#security) (self-managed only):
> Transient LDAP errors can cause users to be blocked and unable to log in. If the transient error is resolved, GitLab now rechecks
> LDAP and unblocks them if another authentication method (such as SAML or OAuth) is configured and used as the sign-in method and the user was blocked using LDAP.
Authentication and Authorization[Topics selection in project settings](https://docs.gitlab.com/ee/user/project/settings/#general-project-settings):
> In this release, thanks to [Jonas Wälter's](https://gitlab.com/wwwjon) contributions, adding topics in project settings is easier than ever. Previously, to add a topic, you had to manually enter each topic and multiple topics had to be comma-separated.
> Now you can select multiple topics from a dropdown list, making topic selection efficient and more convenient.
Projects[Contribution calendar aligned to configured timezone](https://docs.gitlab.com/ee/user/profile/#set-your-time-zone):
> Previously, your contribution calendar was aligned with the server's timezone instead of your local timezone. Large differences between the two timezones could make it appear that you contributed a day earlier or later than you actually did.
>
> Now, contribution calendars are aligned with your local zone, if set. Others can hover over activity to view your local date and time information, to compare their local timezone with your own.
>
> Thanks to [Dave Barr](https://gitlab.com/davebarr) for this contribution!
Authentication and Authorization[VSA deep link for URL query parameters](https://docs.gitlab.com/ee/user/analytics/value_stream_analytics.html#filter-value-stream-analytics-data):
> In previous releases we added the ability to filter Value Stream Analytics by attributes such as labels, milestones, and assignees. In this release, we've enhanced this by adding deep links for query parameters. This creates a hyperlink from the custom query that you can send as a URL to your peers for collaboration, or save as a bookmark for future use.
Value Stream Management[Order deployment by deployed time](https://docs.gitlab.com/ee/ci/environments/#view-environments-and-deployments):
> Currently, the environment page sorts the list of deployments by the Created date, which is associated with the commit SHA change. To make it easier to view deployments over time, we have changed the default sorting order of this list to be by the `finished_at` field rather than the date of the commit. You can now see the running and most recently completed deployments at the top of the page and the rest of your deployments in descending order by the deployed time.
Release Orchestration[Cleaner diffs for Jupyter Notebook files](https://docs.gitlab.com/ee/user/project/repository/jupyter_notebooks/#cleaner-diffs):
> Jupyter notebooks are key to data scientists' and machine learning engineers' workflows, but the file structure makes code review challenging. Often, the files can't be reviewed properly, and users are forced to accept those changes or treat their repositories as stores of data versus collaborative projects.
>
> Now GitLab automatically strips out the noise and displays a cleaner version of the diff for these files. Human-readable diffs make it easier to review the substance of the change, without worrying about the formatting pieces that Jupyter Notebooks need.
Code Review[Merge commit message template](https://docs.gitlab.com/ee/user/project/merge_requests/commit_templates.html):
> Merge commits can provide important context to the commit history of a project about what was merged. However, if you don't edit the merge commit prior to merging, other users are forced to navigate to a merge request to gain additional context about why the changes were made.
>
> Project maintainers can now configure a default merge commit message template. This allows projects to specify a standard merge commit, and use variables to provide additional details in these messages. This additional context helps the next developer when trying to understand why the change was made, by providing the potential to make all the relevant information available in the merge commit.
>
> Thanks to [Piotr](https://gitlab.com/trakos) for this amazing contribution!
Code Review[GitLab Workflow authentication with environment variables](https://gitlab.com/gitlab-org/gitlab-vscode-extension#set-token-with-environment-variables):
> In automated development environments, like Gitpod, configuration of [GitLab Workflow](https://marketplace.visualstudio.com/items?itemName=GitLab.gitlab-workflow) for Visual Studio Code requires loading the editor and then setting the personal access token for GitLab each time. This process is time consuming, error prone, and leads to multiple or duplicate use of access tokens.
>
> With the release of GitLab Workflow [v3.36.0](https://gitlab.com/gitlab-org/gitlab-vscode-extension/-/blob/main/CHANGELOG.md#3360-2021-11-08) the extension now supports configuration via environment variables. Using environment variables enables you to configure the authentication once. Each VS Code instance is then able to authenticate even when the previous VS Code instance has been deleted.
Editor Extension[View file tree when reviewing in Visual Studio Code](https://gitlab.com/gitlab-org/gitlab-vscode-extension#merge-request-reviews):
> When you review a merge request in [GitLab Workflow](https://marketplace.visualstudio.com/items?itemName=GitLab.gitlab-workflow) extension for VS Code, it provides a flat file list to navigate the changes. The flat file list lacks context, and can make it hard to understand where the changes are. In large codebases where files might have the same names across different directory paths, this can be even more problematic when reviewing.
>
> With the release of [v3.37.0](https://gitlab.com/gitlab-org/gitlab-vscode-extension/-/blob/main/CHANGELOG.md#3370-2021-11-11), the GitLab Workflow extension now provides a toggle to switch between a flat list and a file tree view. This file tree view brings additional path information to help you navigate the changes, and get a complete picture of the merge request.
>
> Thanks to [Liming Jin](https://gitlab.com/jinliming2) for the amazing contribution!
Editor Extension[Git fetch resource optimizations](https://docs.gitlab.com/ee/update/#1450):
> We improved the [performance of traffic between Workhorse and Gitaly](https://gitlab.com/gitlab-com/gl-infra/scalability/-/issues/1193#note_731767857), resulting in `git fetch` now using fewer GitLab server resources. This change can cause issues on self-managed GitLab if a gRPC proxy is deployed between Workhorse and Gitaly. If you deployed a gRPC proxy between Workhorse and Gitaly, Workhorse can no longer connect. As a workaround, disable the temporary [workhorse_use_sidechannel feature flag](https://docs.gitlab.com/ee/administration/feature_flags.html#enable-or-disable-the-feature). If you need a proxy between Workhorse and Gitaly, use a TCP proxy.
Gitaly[Tables in wikis support block-level elements](https://docs.gitlab.com/ee/user/project/wiki/#use-the-content-editor):
> GitLab 14.1 introduced WYSIWYG editing for tables in the new wiki editor, but the types of content supported in table cells were limited by the underlying Markdown implementation: you couldn't add block-level elements like lists, code blocks, or pull quotes inside a table. Now, in GitLab 14.5, these block-level elements are fully supported inside table cells. You can insert lists, code blocks, paragraphs, headings, and even nested tables inside a table cell, giving you more flexibility and freedom to format your content to meet your needs.
Wiki[Sticky toolbar when editing wiki pages](https://docs.gitlab.com/ee/user/project/wiki/):
> When you edit long wiki pages, the editor grows vertically to fit your content. In previous versions, the editor could become so long that the formatting toolbar icons disappeared. When writing in raw Markdown, this can be frustrating but you can overcome it using keyboard shortcuts. However, the toolbar is a much more critical component of the new rich Markdown editor, so having this UI unavailable on the screen requires you to scroll vertically, away from your content, to access core features.
>
> Now, in GitLab 14.5, the formatting toolbar remains fixed at the top of the input field, allowing you easy and persistent access to these convenient features, even when editing very long documents.
>
> Thank you [Mehul Sharma](https://gitlab.com/mehulsharma) for contributing this helpful improvement!
Wiki[Add pipeline mini graph to the pipeline editor](https://docs.gitlab.com/ee/ci/pipelines/#pipeline-mini-graphs):
> Tracking the status of a running pipeline can involve significant context switching because you sometimes have to stop what you are doing to go check the pipeline page. Previously, the pipeline editor only showed the overall pipeline status and provided a link to the pipeline. In this release, we are adding the pipeline mini graph to the pipeline editor to make it easier for you to see the status of individual jobs without leaving the editor.
Pipeline Authoring[Improved UI for runners in the Admin Area](https://docs.gitlab.com/ee/administration/admin_area.html#administering-runners):
> Previously, if you were a GitLab administrator, you could not easily find runners by instance, group, or project. The search and filter limitations made it difficult and inefficient to locate a runner when troubleshooting CI/CD job execution issues.
>
> This release includes an initial update to the Runners page (**Admin Area > Runners**). The new layout helps you find runners more quickly and enables GitLab to provide future improvements for runner fleet management. The key improvements in this redesign are tabs that filter the list of runners by type, and indicators that show runners that have not recently connected to GitLab.
GitLab Runner[GitLab Runner 14.5](https://docs.gitlab.com/runner):
> We’re also releasing GitLab Runner 14.5 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:
>
> - [Add `podTerminationGracePeriodSeconds` and `cleanupGracePeriodSeconds` configuration options to the Kubernetes executor](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/25668)
>
> #### Bug Fixes:
>
> - [Kubernetes executor ignores Docker `ENTRYPOINT`](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/4125)
> - [Kubernetes builds on Windows nodes fail without `shell = "pwsh"`](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/28153)
> - [GitLab Runner doesn't clean up git lock files for submodules](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/3292)
>
> The list of all changes is in the GitLab Runner [CHANGELOG](https://gitlab.com/gitlab-org/gitlab-runner/blob/14-5-stable/CHANGELOG.md).
GitLab Runner[Extract package metadata for npm packages](https://docs.gitlab.com/ee/user/packages/npm_registry/#npm-metadata):
> You can use the GitLab Package Registry to publish and share npm packages alongside your source code and pipelines. Prior to this release, however, GitLab did not extract all of the relevant metadata detailed in your `package.json` file. This is especially problematic when npm or Yarn relies on one of those fields. For example, the [`bin` field](https://docs.npmjs.com/cli/v6/configuring-npm/package-json#bin) defines executables to insert in `$PATH`. Without that field, your executables do not work.
>
> As of this release, GitLab now extracts the [abbreviated metadata](https://github.com/npm/registry/blob/master/docs/responses/package-metadata.md#abbreviated-version-object) for npm packages, including the `bin` field and others. If you publish packages that have one or more executable files to install into the `$PATH`, you can now rely on the GitLab Package Registry to work seamlessly. Please note that this change applies to new packages only. Any packages already published to the registry must be updated for the change to take effect. In addition, GitLab only extracts the abbreviated metadata, which excludes certain fields. [GitLab-#344107](https://gitlab.com/gitlab-org/gitlab/-/issues/344107) proposes extracting the full metadata set.
Package Registry[Additional Secret Detection pattern support](https://docs.gitlab.com/ee/user/application_security/secret_detection/#supported-secrets):
> We've updated the GitLab Secret Detection scanner to detect 47 new 'well-identifiable' secret patterns for widely used applications. This brings the GitLab Secret Detection detection up to over 90 detectable patterns.
>
> If you are a SaaS application vendor and your app generates secret tokens with well-identifiable patterns, and you'd like GitLab to be able to detect them, please add your regex pattern and a few invalid sample tokens [in a comment on this issue](https://gitlab.com/gitlab-org/gitlab/-/issues/345453) and we'll get them added to GitLab Secret Detection.
Secret Detection[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.5. These updates bring additional coverage, bug fixes, and improvements.
>
> - semgrep updated to version 0.72.0 - [MR](hhttps://gitlab.com/gitlab-org/security-products/analyzers/semgrep/-/merge_requests/92), [Changelog](https://gitlab.com/gitlab-org/security-products/analyzers/semgrep/-/blob/main/CHANGELOG.md#v2140)
> - various bug fixes for timeouts, crashes, and rule corrections. See changelog link for more details.
> - flawfinder internal packages updated to version 2.14.7 - [MR](https://gitlab.com/gitlab-org/security-products/analyzers/flawfinder/-/merge_requests/69), [Changelog](https://gitlab.com/gitlab-org/security-products/analyzers/flawfinder/-/blob/master/CHANGELOG.md#v2147)
> - gosec updated to version 2.9.1 - [MR](https://gitlab.com/gitlab-org/security-products/analyzers/gosec/-/merge_requests/132), [Changelog](https://gitlab.com/gitlab-org/security-products/analyzers/gosec/-/blob/master/CHANGELOG.md#v334)
> - Fix the SBOM generation step in the release action
> - Phase out support for go version 1.15 because current ginko is not backward compatible
> - sobelow internal packages updated - [MR](https://gitlab.com/gitlab-org/security-products/analyzers/sobelow/-/merge_requests/70), [Changelog](https://gitlab.com/gitlab-org/security-products/analyzers/sobelow/-/blob/master/CHANGELOG.md#v2142)
> - We thank [@rbf](https://gitlab.com/rbf) for their contributions ([1](https://gitlab.com/gitlab-org/security-products/analyzers/sobelow/-/merge_requests/67),[2](https://gitlab.com/gitlab-org/security-products/analyzers/sobelow/-/merge_requests/65),[3](https://gitlab.com/gitlab-org/security-products/analyzers/sobelow/-/merge_requests/64)) to our Sobelow analzer which enables new detection rules, and opens up the door for future improvements and additional rules in the future.
> - PMD updated to version 6.40.0 - [MR](https://gitlab.com/gitlab-org/security-products/analyzers/pmd-apex/-/merge_requests/72), [Changelog](https://gitlab.com/gitlab-org/security-products/analyzers/pmd-apex/-/blob/master/CHANGELOG.md)
> - Apex language support to v54.0
> - Various improvements and bugfixes for rulesets.
> - spotbugs updated to version 4.5.0 - [MR](https://gitlab.com/gitlab-org/security-products/analyzers/spotbugs/-/merge_requests/115), [Changelog](https://gitlab.com/gitlab-org/security-products/analyzers/spotbugs/-/blob/master/CHANGELOG.md#v2288)
> - false negative fixes
>
> 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[New GitLab access token prefix and detection](https://docs.gitlab.com/ee/user/profile/personal_access_tokens.html):
> With GitLab 14.5 we have updated the GitLab [Personal Access Tokens](https://docs.gitlab.com/ee/user/profile/personal_access_tokens.html) and [Project Access Tokens](https://docs.gitlab.com/ee/user/project/settings/project_access_tokens.html) to include a standard prefix, `glpat-` by default for both GitLab.com and GitLab self-managed instances. We've also updated our Secret Detection scanning to detect this new pattern which will help protect you against accidentally leaked GitLab access tokens in commits.
>
> This improvement helps make it easy to detect GitLab tokens leaked in commits and builds on [community contribution](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/20968) improvements added in Gitlab 13.7 that [allowed Admins to set Personal Access Token prefixes at the instance level](https://docs.gitlab.com/ee/administration/settings/account_and_limit_settings.html#personal-access-token-prefix), shoutout to @max-wittig and @dlouzan at Siemens for this contribution! Existing access tokens will not be modified but any new tokens will follow this new pattern or the custom pattern set by your self-managed GitLab instance.
>
> If you would like to detect GitLab Personal Access Tokens and Project Access Tokens you can use the following regex detection pattern: `glpat-[0-9a-zA-Z\-]{20}`.
Secret Detection[Introducing Infrastructure as Code (IaC) security scanning](https://docs.gitlab.com/ee/user/application_security/iac_scanning/):
> With Gitlab 14.5 we're introducing security scanning for Infrastructure as Code (IaC) configuration files. Like all our SAST scanners, we've chosen to make this capability available for all customers for free to encourage secure coding practices with the rise of IaC. The initial version of this IaC security scanner supports configuration files for Terraform, Ansible, AWS CloudFormation, and Kubernetes and is based on the open-source [Keeping Infrastructure as Code Secure (KICS) project](https://kics.io/). This new IaC scanning capability joins our [existing Kubernetes manifest SAST scanner](https://docs.gitlab.com/ee/user/application_security/sast/#enabling-kubesec-analyzer).
>
> If you're familiar with GitLab SAST, GitLab's IaC scanning works exactly the same and supports the same features including a standalone IaC scanning [CI configuration file](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Jobs/SAST-IaC.latest.gitlab-ci.yml), [UI based enablement tool](https://docs.gitlab.com/ee/user/application_security/iac_scanning/#enable-iac-scanning-via-an-automatic-merge-request) on the Security Configuration Page and support for all our Ultimate tier [Vulnerability Management features](https://docs.gitlab.com/ee/user/application_security/vulnerability_report/) including Security Dashboards and Merge Request widget. With this new IaC scanning template, we've also made it easy to extend our IaC scanning with additional scanners and welcome community contributions [using our secure scanner integration framework](https://docs.gitlab.com/ee/development/integrations/secure.html).
>
> You can read more about IaC scanning in [GitLab’s documentation](https://docs.gitlab.com/ee/user/application_security/iac_scanning/) or [Checkmarx’s press release](https://checkmarx.com/press-releases/checkmarx-kics-integrated-into-gitlab-14-5-as-default-iac-code-scanner/).
SAST[Basic authentication for alert HTTP endpoints](https://docs.gitlab.com/ee/operations/incident_management/integrations.html#basic-authentication):
> In the past, you needed a bearer token to authenticate to an alerts HTTP endpoint. Beginning with this release, you can also authenticate with Basic HTTP authentication, either through the headers or in the URL.
Incident Management[Restrict incident creation permissions to at least the Reporter role](https://docs.gitlab.com/ee/operations/incident_management/incidents.html):
> You may have experienced a time where you created an incident when you actually meant to create an issue. Incidents are a specific issue-type, with a unique user interface and workflow that represent service disruptions or outages. In this release, only users with at least the Reporter role can create incidents. Restricting these permissions will help minimize the number of accidentally-created incidents.
Incident Management