GitLab.org/GitLab: Release v14.8.0-ee
Name: GitLab
Owner: GitLab.org
Release: GitLab 14.8
Released: 2022-02-22
License: MIT
Release Assets:
#### [Ultimate](https://about.gitlab.com/pricing/ultimate/)
[Display average and median for DORA4 metrics graphs](https://docs.gitlab.com/ee/user/analytics/ci_cd_analytics.html#devops-research-and-assessment-dora-key-metrics):
> In this release, we've added the ability to view average deployment frequency rates and median lead times in your DORA4 metrics. You can now continuously monitor your DevOps process and quickly identify how you are actually performing versus your average or median pace.
Value Stream Management[Additional data for deployment frequency graph](https://docs.gitlab.com/ee/user/analytics/ci_cd_analytics.html#deployment-frequency-charts):
> In this release, we've added the number of deployments and deployment frequency to DORA metrics displayed under CI/CD Analytics:
>
> - Number of deployments shows the number of successful deployments in the date range
> - Deployment frequency shows the average number of successful deployments.
>
> This data previously appeared only in value stream analytics. With this additional information, you can gain a better understanding of your team's deployment frequency for better tracking.
Value Stream Management[Mutual TLS for DAST scans](https://docs.gitlab.com/ee/user/application_security/dast/#use-mutual-tls):
> Starting in GitLab 14.8, Mutual TLS is now available for DAST scans. This allows for a target application server to verify that requests are from a known source. Sites that utilize mutual TLS can now be scanned by DAST. To use mutual TLS, a masked variable named `DAST_PKCS12_CERTIFICATE_BASE64` must be created and the base64-encoded PKCS12 certificate’s value must be stored in that variable. In addition, a masked variable name `DAST_PKCS12_PASSWORD` should be used to store the PKCS12 certificate’s password. Please note that this feature is not yet supported by the browser-based DAST scanner, which is still in beta.
DAST[On-demand security scan index view](https://docs.gitlab.com/ee/user/application_security/dast/#view-on-demand-dast-scans):
> Find all your on-demand DAST and DAST API scans on a single page. We have introduced a new index page for on-demand scans that shows your in-progress scans, previously run scans, saved scans, and scheduled scans. From this index page, you can find specific scans easily or re-run scans that have already finished. In previous versions of GitLab, to see on-demand scans that were in-progress or had finished, you needed to search through the pipelines page to find the right pipeline. Saved on-demand scans were located in the Security & Compliance configuration section. To find scheduled scans, you needed to look at each saved scan individually to see their schedule. All of those activities are now rolled into one page to make it easier to run on-demand security testing outside of CI/CD builds, MRs, or pipelines.
DAST, API Security[Coverage-guided fuzz testing corpus management](https://docs.gitlab.com/ee/user/application_security/coverage_fuzzing/#corpus-registry):
> In previous versions of GitLab, if you wanted to use a seed corpus in a coverage-guided fuzz test, you would need to upload the file to a location and define the path to the corpus via the `COVFUZZ_SEED_CORPUS` variable. The management of any corpus that you might use in a test was completely manual, including updating the corpus after running a test. With GitLab 14.8, corpus management is now integrated into the Security & Compliance Configuration section. By setting the `COVFUZZ_USE_REGISTRY` to `"true"`, setting the `COVFUZZ_GITLAB_TOKEN` variable to a personal access token, and specifying the corpus name via the `COVFUZZ_CORPUS_NAME` variable, corpus management can be easily integrated into your testing workflow. Corpus files can be automatically added to the registry from pipelines as coverage-guided fuzz tests are run. They can also be automatically updated with the artifacts output from a coverage-guided fuzz test job, rather than only manually updated. If a corpus is no longer needed, you can delete it directly from the registry page. Corpus files that are listed in the registry can also be downloaded for inspection or use elsewhere. This management UI provides a major improvement to the coverage-guided fuzz testing experience when seed corpuses are used.
Fuzz Testing[Customize built-in SAST and Secret Detection rules](https://docs.gitlab.com/ee/user/application_security/sast/index.html#customize-rulesets):
> You can now customize the predefined rules that are included in GitLab [Static Application Security Testing (SAST)](https://docs.gitlab.com/ee/user/application_security/sast/index.html#customize-rulesets) and [Secret Detection](https://docs.gitlab.com/ee/user/application_security/secret_detection/#custom-rulesets). For each rule, you can change the name, message, description, and severity fields to help your DevSecOps teams know which vulnerabilities to fix first.
>
> This is an addition to the existing customization options in GitLab Ultimate, which allowed you to disable, replace, or extend predefined rules.
>
> Your customizations are reflected in the `gl-sast-report.json` and `gl-secret-detection-report.json` [artifacts](https://docs.gitlab.com/ee/user/application_security/sast/#reports-json-format), used when [evaluating merge request approval rules](https://docs.gitlab.com/ee/user/application_security/index.html#security-approvals-in-merge-requests), and shown [in the Vulnerability Report](https://docs.gitlab.com/ee/user/application_security/vulnerability_report/).
SAST, Secret Detection[Security approval policies](https://docs.gitlab.com/ee/user/application_security/policies/scan-result-policies):
> GitLab now supports flexible security approvals as the replacement for the deprecated Vulnerability-Check feature. Security approvals are similar to Vulnerability-Check in that both can require approvals for MRs that contain security vulnerabilities. However, security approvals improve the previous experience in several ways:
>
> - Users can choose who is allowed to edit security approval rules. An independent security or compliance team can therefore manage rules in a way that prevents development project maintainers from modifying the rules.
> - Multiple rules can be created and chained together to allow for filtering on different severity thresholds for each scanner type.
> - A two-step approval process can be enforced for any desired changes to security approval rules.
> - A single set of security policies can be applied to multiple development projects to allow for ease in maintaining a single, centralized ruleset.
>
> Security approval policies can be used alongside the existing Vulnerability-Check feature, as the two policies are additive and don't conflict. However, we encourage users to migrate their Vulnerability-Check rules over to security approval policies. Vulnerability-Check rules are now [deprecated](https://docs.gitlab.com/ee/update/deprecations.html#vulnerability-check), and are scheduled for removal in GitLab 15.0. Self managed users will need to enable the `scan_result_policy` feature flag prior to using this feature. To get started, navigate to **Security & Compliance > Policies** and create a new Scan Result type policy.
Security Orchestration[Filters added to Geo sites dashboard](https://docs.gitlab.com/ee/administration/geo/):
> The Geo sites dashboard allows administrators to view and edit details about their Geo primary and secondary sites. For customers operating multiple secondary sites, it can take time to scroll through the list of sites and identify the ones that need attention. We have added options to filter by health status, site name, or its URL. This makes it easier and faster to find what you are looking for on the dashboard.
Geo-replication, Disaster Recovery[Deployment approval API](https://docs.gitlab.com/ee/ci/environments/deployment_approvals.html):
> We are excited to introduce deployment approval via API. Prior to this feature, teams had the ability to protect an environment from any changes by requiring a manual job to be executed in a pipeline as a workaround. Now, deployment approval is a first-class concept in our platform. Teams can configure a number of approvers for a specific environment and use a new API endpoint to execute an approval or rejection of a deployment to that environment. This capability enables teams to create workflows to obtain the proper approvals before deploying software to production or other protected environments.
Environment Management[User impersonation audit events for groups](https://docs.gitlab.com/ee/administration/audit_events.html#group-events):
> GitLab now provides audit events on the group audit events page for
> [user impersonation](https://docs.gitlab.com/ee/administration/admin_area.html#user-impersonation) starting and stopping. This was previously
> only available on a page unavailable to GitLab SaaS customers. We are excited to bring
> it to the group page which allows both self-managed and SaaS users to view these events!
>
> These events are helpful to understand if an administrator impersonated a user in your group and any actions that the
> administrator took as the impersonated user. You can correlate:
>
> - Any actions a user took.
> - When impersonation was happening.
>
> This can help you understand if it was actually the user performing certain actions or an administrator impersonating them. The
> absence of impersonation events in the audit log is also a way to be confident that a given user actually performed given
> actions, rather than someone impersonating them.
Audit Events[Additional display options for roadmaps](https://docs.gitlab.com/ee/user/group/roadmap/index.html#roadmap-settings):
> In this release, we have introduced additional progress tracking capabilities to roadmaps. You can now view the percentage of completed epics based on issue count instead of issue weight. This functionality is useful for organizations that are using Kanban or other methodologies that don't require their teams to set a weight on issues.
>
> You can now also customize the level of milestones to include in your roadmap, allowing you to tailor your view to meet the needs of your audience.
Portfolio Management[The agent server for Kubernetes is enabled by default](https://docs.gitlab.com/ee/administration/clusters/kas.html) (self-managed only):
> The first step for using the agent for Kubernetes in self-managed instances is to enable the agent server, a backend service for the agent for Kubernetes. In GitLab 14.7 and earlier, we required a GitLab administrator to enable the agent server manually. As the feature matured in the past months, we are making the agent server enabled by default to simplify setup for GitLab administrators. Besides being enabled by default, the agent server accepts various configuration options to customize it according to your needs.
Infrastructure as Code[GitLab chart improvements](https://docs.gitlab.com/charts) (self-managed only):
> - GitLab 14.8 includes an update of the [Prometheus Helm chart](https://prometheus-community.github.io/helm-charts) from `11.16.9` to `15.0.4`, which brings us from Prometheus `2.21.0` to `2.31.1`. Prometheus `2.31.1` includes various features, enhancements, and fixes outlined in the [Prometheus release notes](https://github.com/prometheus/prometheus/releases).
Cloud Native Installation[Omnibus improvements](https://docs.gitlab.com/omnibus) (self-managed only):
> - GitLab 14.8 includes [Mattermost 6.3](https://mattermost.com/blog/mattermost-v6-3-is-now-available/), with Playbooks translations and streamlined notifications. Boards is promoted to Generally Available and includes change notifications, person avatars, and comment sort order. This version also includes [security updates](https://mattermost.com/security-updates/) and upgrade from earlier versions is recommended.
> - Securing Consul cluster in GitLab 14.8 is now easier. Users can now configure mTLS and Gossip encryption on Consul nodes to secure the communication between Consul agents and the clients.
> - GitLab 14.8 also includes packages for [SUSE Enterprise Linux Server (SLES) 15 SP2](https://www.suse.com/releasenotes/x86_64/SUSE-SLES/15-SP2/index.html).
Omnibus Package[Invite members and groups by using a modal](https://docs.gitlab.com/ee/user/project/members/#add-users-to-a-project):
> Inviting members or groups to projects can now be completed through a modal experience. You no longer have to complete these steps in a form. The move to the modal interaction makes it easier for you to add members and groups to projects or groups from anywhere in the product, and minimizes disruption to your workflow.
Authentication and Authorization[Delete groups at the parent group level](https://docs.gitlab.com/ee/user/group/#remove-a-group):
> In this milestone, we've worked on one of the initial steps to reach feature parity between group owners (in any installation base) and administrator-only functionality that exists solely in the administrator panel for self-managed users.
>
> Group owners can now delete a group and its subgroups from the parent group level. Until now, group owners had to go into each individual group to delete them, which was timely and inefficient. Group owners can now view all groups and delete them from a single place.
Subgroups[Set custom rate limiting for GitLab Pages](https://docs.gitlab.com/ee/administration/pages/#rate-limits):
> We have added rate limiting capabilities to our Pages feature. Unlimited or undesired traffic (such as a Denial of Service attack) to hosted pages can cause unexpected availability issues or even downtime for users. With this update, rate limiting can be enforced per specific client IP addresses and per specific hosted pages domain. Limits can be configured for each independently. When enabled and traffic exceeds these limits, requests will be reported and rejected.
Pages[Latest Release badge for the project](https://docs.gitlab.com/ee/ci/pipelines/settings.html#latest-release-badge):
> We have added a new badge so you can easily see the version of your latest release right in the project page.
>
> Thank you [Jason D'Amour](https://gitlab.com/jason.damour) for your contribution!
Release Orchestration[Support for ecdsa-sk and ed25519-sk SSH keys](https://docs.gitlab.com/ee/ssh/#generate-an-ssh-key-pair-for-a-fidou2f-hardware-security-key):
> [OpenSSH 8.2](https://www.openssh.com/releasenotes.html#8.2) added support for FIDO/U2F hardware authenticators with new
> ecdsa-sk and ed25519-sk key types.
>
> GitLab now supports these key types, allowing users to take advantage of hardware-backed SSH authentication.
Authentication and Authorization[Add default issue and merge request templates in a project's repository](https://docs.gitlab.com/ee/user/project/description_templates.html#set-a-default-template-for-merge-requests-and-issues):
> In addition to defining [default issue and merge request description templates](https://docs.gitlab.com/ee/user/project/description_templates.html#set-a-default-template-for-merge-requests-and-issues) in project settings, you can now set default templates in the `.gitlab`
> directory of a project's repository.
> Do it by creating a `Default.md` file in the issue or merge request templates folders.
> If default templates exist in both the project's settings and in the repository, the template in the settings
> takes precedence.
>
> Thanks for the contribution `@davebarr`!
Team Planning[Improved cleanup of gitconfig file](https://docs.gitlab.com/ee/administration/gitaly/index.html):
> Gitaly parses `.gitconfig` files that can grow very large when not maintained. Large `.gitconfig` files can heavily impact the performance of short-running Git commands. GitLab 14.8:
>
> - Resolves a known issue where we were not correctly cleaning up certain configuration keys as expected.
> - Proactively removes empty configuration sections.
>
> Combined, these updates improved performance by 50% or more for these short-running Git commands, resulting in a substantial reduction during regular Git operations!
Gitaly[View read-only runner details in the Admin Area](https://docs.gitlab.com/ee/administration/admin_area.html#administering-runners) (self-managed only):
> You can now view the details of a runner in the Admin Area. This new view aims to provide the most valuable information about each runner associated with your GitLab instance. You can view last contact, runner version, and assigned projects, which is now paginated. In the new paginated jobs tab, you can also view a full list of jobs run by the Runner, which helps you view, search, and analyze CI/CD job execution history quickly.
GitLab Runner[Use the CI Lint API with other branches or tags](https://docs.gitlab.com/ee/api/lint.html#validate-a-projects-ci-configuration):
> Previously, the project CI lint API endpoint for validating CI/CD configuration was only capable of parsing configuration that exists in the default branch. In this release we've added an optional `ref` parameter to the endpoint, so you can now lint the CI/CD configuration you have in other branches or tag refs.
Pipeline Authoring[Improve pipeline index page layout](https://docs.gitlab.com/ee/ci/pipelines/#view-pipelines):
> GitLab values efficiency, so we want to empower you to easily navigate our platform, especially when viewing jobs and pipelines. You might have noticed that the many options and columns on the job and pipeline index pages make it difficult to understand what GitLab CI/CD information is most relevant to your project.
>
> Now, we have restructured these views so you can quickly get the pipeline information you need, including status, name of pipeline, merge request ID, and commit SHA.
Continuous Integration (CI)[GitLab Runner 14.8](https://docs.gitlab.com/runner):
> We’re also releasing GitLab Runner 14.8 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:
>
> - [GitLab Runner for Apple silicon M1](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/26561)
>
> #### Bug Fixes:
>
> - [Kubernetes executor failed quota: quota limit error](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/28098)
> - [Temporary Docker volumes cleaned up after each job](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/27022)
>
> The list of all changes is in the GitLab Runner [CHANGELOG](https://gitlab.com/gitlab-org/gitlab-runner/blob/14-8-stable/CHANGELOG.md).
GitLab Runner[Auto-completion of keywords in the Pipeline Editor](https://docs.gitlab.com/ee/ci/pipeline_editor/index.html#validate-ci-configuration):
> Writing a valid GitLab CI/CD pipeline can be difficult regardless of whether you're a novice or more advanced user. Syntax structure should be accurate and even a small typo or misconfiguration could cause your pipeline to be invalid, introducing more work to find the source of the problem. In this release, we've added auto-completion of CI/CD keywords to the pipeline editor, which will greatly increase your efficiency when writing and debugging pipelines. You'll be more confident that your pipeline will run the way you want it the very first time it runs.
Pipeline Authoring[Static Analysis analyzer updates](https://docs.gitlab.com/ee/user/application_security/sast/analyzers):
> GitLab Static Analysis includes [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. The following analyzer updates were published during the 14.8 release. These updates bring additional coverage, bug fixes, and improvements.
>
> - Bandit analyzer updated to version 1.7.2. See [CHANGELOG](https://gitlab.com/gitlab-org/security-products/analyzers/bandit/-/blob/master/CHANGELOG.md#v2123) for details.
> - New rules for SNMP configuration
> - Resolved CVEs in Alpine Linux
> - ESLint analyzer updated to version 6.2.0 of `eslint-plugin-html` and version 7.28.0 of `eslint-plugin-react`. See [CHANGELOG](https://gitlab.com/gitlab-org/security-products/analyzers/eslint/-/blob/master/CHANGELOG.md#v2244) for details.
> - Add, fix, and update various rules
> - MobSF analyzer updated to version 3.4.6. See [CHANGELOG](https://gitlab.com/gitlab-org/security-products/analyzers/mobsf/-/blob/master/CHANGELOG.md#v2140) for details.
> - Reduce severity of some existing rules
> - Add new rules for Android encryption settings and API calls
> - Gosec analyzer updated to version 2.9.6. See [CHANGELOG](https://gitlab.com/gitlab-org/security-products/analyzers/gosec/-/blob/master/CHANGELOG.md#v350) for details.
> - Fix false negatives in some cases
> - Semgrep analyzer updated to version 0.82.0. See [CHANGELOG](https://gitlab.com/gitlab-org/security-products/analyzers/semgrep/-/blob/main/CHANGELOG.md#v2180) for details.
> - Improve performance
> - Add symbolic propagation for simple definitions, `x = foo.bar(); x.baz()` matching `foo.bar().baz()`
> - Fix various bugs
> - Kics analyzer updated to version 1.5.1. See [CHANGELOG](https://gitlab.com/gitlab-org/security-products/analyzers/kics/-/blob/main/CHANGELOG.md#v122) for details.
> - Add and update rules, fix various issues
> - Disable network requests to send crash reports and fetch modified rule descriptions
> - Kubesec analyzer updated to version 2.11.4. See [CHANGELOG](https://gitlab.com/gitlab-org/security-products/analyzers/kubesec/-/blob/master/CHANGELOG.md#v2162) for details.
> - NodeJS-scan analyzer updated to version 0.3.1. See [CHANGELOG](https://gitlab.com/gitlab-org/security-products/analyzers/nodejs-scan/-/blob/master/CHANGELOG.md#v2220) for details.
> - Upgrade dependencies
> - Fix and update rules
> - Secrets analyzer updated to fix various issues and rules. See [CHANGELOG](https://gitlab.com/gitlab-org/security-products/analyzers/secrets/-/blob/master/CHANGELOG.md#v3248) for details.
> - PMD Apex analyzer updated to version 6.42.0. See [CHANGELOG](https://gitlab.com/gitlab-org/security-products/analyzers/pmd-apex/-/blob/master/CHANGELOG.md#v21212) for details.
> - Add new rule
> - SpotBugs analyzer dependencies updated. See [CHANGELOG](https://gitlab.com/gitlab-org/security-products/analyzers/spotbugs/-/blob/master/CHANGELOG.md#v2291) for details.
>
> We've also updated the Go version used in the analyzers to address recent security issues in Go.
>
> If you [include the GitLab-managed 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 don't need to do anything to receive these updates. However, if you override or customize your own CI/CD template, you need to update your CI/CD configurations. To remain on a specific version of any analyzer, you can [pin to a minor version of an analyzer](https://docs.gitlab.com/ee/user/application_security/sast/#pinning-to-minor-image-version). Pinning to a previous version prevents you from receiving automatic analyzer updates and requires you to manually bump your analyzer version in your CI/CD template.
SAST, Secret Detection[SAST severities now available for .NET](https://docs.gitlab.com/ee/user/application_security/vulnerabilities/severities):
> Previously, GitLab SAST returned an `Unknown` severity for all vulnerabilities identified in .NET projects. Now, .NET results are assigned a severity value based on the [CWE](https://cwe.mitre.org) associated with the finding.
>
> Severity levels are included in the [`gl-sast-report.json`](https://docs.gitlab.com/ee/user/application_security/sast/#reports-json-format) artifact in all GitLab tiers.
>
> With GitLab Ultimate, these new severity levels make it easier to secure your .NET projects by [requiring approval for merge requests](https://docs.gitlab.com/ee/user/application_security/index.html#vulnerability-check-rule) and [analyzing your overall risk posture](https://docs.gitlab.com/ee/user/application_security/vulnerability_report/).
>
> For backwards compatibility reasons, severities will not appear in results by default until you upgrade to GitLab 15.0.
> To receive .NET SAST results with severity values before then, 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), v3, of the Security Code Scan analyzer.
> You can add this [code snippet](https://gitlab.com/-/snippets/2223915) to your `.gitlab-ci.yml` file to try these new scanning capabilities.
> In GitLab 15.0, we will promote this new version to run by default.
SAST