Feb 22, 2022 - Brian Rhea  

GitLab 14.8 released with new SSH key types and security approval policies

GitLab 14.8 released with new SSH key types, security approval policies, pipeline editor autocomplete, impersonation audit events and much more!

Today, we are excited to announce the release of GitLab 14.8 with new SSH key types, security approval policies, pipeline editor autocomplete, impersonation audit events, and much more!

These are just a few highlights from the 25+ improvements in this release. Read on to check out all of the great updates below.

To preview what's coming in next month’s release, check out our Upcoming Releases page, which includes our 14.9 release kickoff video.

Join us for an upcoming event

GitLab MVP badge

This month's Most Valuable Person (MVP) is Piotr Stankowski

Beginning in 14.5, Piotr worked closely with both product and UX to develop a solution that allowed users the flexibility to create custom templates for their merge commits. In 14.6, he followed up by introducing the same variable-based templates for squash commits, dramatically improving the experience for the various preferences teams have for squashing commits.

In GitLab 14.8, Piotr continued to build upon his improvements to the merge commit and squash commit templates. He’s continued his presence as an amazing partner for product, design, technical writing, and the wider GitLab community by shipping a wonderful UX improvement to show the default value in the template areas. This work further improves users’ understanding of the templates’ current values, and how they can be modified.

Piotr also contributed docs improvements to our merge request API, and added a field to our REST API to unify it with GraphQL.

Thank you, Piotr!

Key improvements released in GitLab 14.8

Support for ecdsa-sk and ed25519-sk SSH keys

OpenSSH 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.

Support for ecdsa-sk and ed25519-sk SSH keys

User impersonation audit events for groups

GitLab now provides audit events on the group audit events page for 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.

User impersonation audit events for groups

Additional display options for roadmaps

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.

Additional display options for roadmaps

Security approval 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, 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 approval policies

Auto-completion of keywords in the Pipeline Editor

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.

Other improvements in GitLab 14.8

Display average and median for DORA4 metrics graphs

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.

Display average and median for DORA4 metrics graphs

Improved cleanup of gitconfig file

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!

Improved cleanup of gitconfig file

Improve pipeline index page layout

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.

Improve pipeline index page layout

View read-only runner details in the Admin Area

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.

View read-only runner details in the Admin Area

Customize built-in SAST and Secret Detection rules

You can now customize the predefined rules that are included in GitLab Static Application Security Testing (SAST) and Secret Detection. 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, used when evaluating merge request approval rules, and shown in the Vulnerability Report.

On-demand security scan index view

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.

On-demand security scan index view

Static Analysis analyzer updates

GitLab Static Analysis includes many security analyzers 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 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 for details.
    • Add, fix, and update various rules
  • MobSF analyzer updated to version 3.4.6. See CHANGELOG 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 for details.
    • Fix false negatives in some cases
  • Semgrep analyzer updated to version 0.82.0. See CHANGELOG 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 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 for details.
  • NodeJS-scan analyzer updated to version 0.3.1. See CHANGELOG for details.
    • Upgrade dependencies
    • Fix and update rules
  • Secrets analyzer updated to fix various issues and rules. See CHANGELOG for details.
  • PMD Apex analyzer updated to version 6.42.0. See CHANGELOG for details.
    • Add new rule
  • SpotBugs analyzer dependencies updated. See CHANGELOG 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 (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. 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.

The agent server for Kubernetes is enabled by default

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.

Filters added to Geo sites dashboard

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.

Filters added to Geo sites dashboard

Omnibus improvements

  • GitLab 14.8 includes Mattermost 6.3, 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 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.

Additional data for deployment frequency graph

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.

Additional data for deployment frequency graph

Delete groups at the parent group level

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.

Delete groups at the parent group level

Add default issue and merge request templates in a project’s repository

In addition to defining default issue and merge request description templates 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!

GitLab Runner 14.8

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:

Bug Fixes:

The list of all changes is in the GitLab Runner CHANGELOG.

Use the CI Lint API with other branches or tags

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.

Coverage-guided fuzz testing corpus management

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.

Coverage-guided fuzz testing corpus management

Mutual TLS for DAST scans

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.

SAST severities now available for .NET

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 associated with the finding.

Severity levels are included in the gl-sast-report.json 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 and analyzing your overall risk posture.

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, v3, of the Security Code Scan analyzer. You can add this code snippet 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.

Deployment approval API

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.

Latest Release badge for the project

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 for your contribution!

Latest Release badge for the project

Set custom rate limiting for GitLab Pages

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.

Invite members and groups by using a modal

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.

Invite members and groups by using a modal

GitLab chart improvements

  • GitLab 14.8 includes an update of the Prometheus Helm chart 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.

Bug fixes

Some of the notable bug fixes in 14.8 are:

Usability improvements

In every release, we make great strides in improving the overall effectiveness and usefulness of our product.

We also have a UI Polish Gallery to track important updates to our interfaces. These updates, while often small, improve your user experience.

In GitLab 14.8, we’re shipping usability improvements for issues, projects, milestones, and much more! We highlight the following changes in GitLab 14.8:


New deprecations and the complete list of all features that are currently deprecated can be viewed in the GitLab documentation.

  • Changes to the `CI_JOB_JWT`
  • Configurable Gitaly `per_repository` election strategy
  • Container Network and Host Security
  • Dependency Scanning Python 3.9 and 3.6 image deprecation
  • Deprecate Geo Admin UI Routes
  • Deprecate custom Geo:db:* Rake tasks
  • Deprecate feature flag PUSH_RULES_SUPERSEDE_CODE_OWNERS
  • Deprecate legacy Gitaly configuration methods
  • Elasticsearch 6.8
  • External status check API breaking changes
  • GraphQL ID and GlobalID compatibility
  • OAuth tokens without expiration
  • Optional enforcement of PAT expiration
  • Optional enforcement of SSH expiration
  • Out-of-the-box SAST support for Java 8
  • Querying Usage Trends via the `instanceStatisticsMeasurements` GraphQL node
  • REST API Runner will not accept `status` filter values of `active` or `paused`
  • REST API endpoint to list group runners no longer accepts `project_type` value for `type` argument
  • REST and GraphQL API Runner usage of `active` replaced by `paused`
  • Reminder: support for NFS repository storage
  • Request profiling
  • Required pipeline configurations in Premium tier
  • Retire-JS Dependency Scanning tool
  • SAST analyzer consolidation and CI/CD template changes
  • SAST support for .NET 2.1
  • Secret Detection configuration variables deprecated
  • Secure and Protect analyzer images published in new location
  • Secure and Protect analyzer major version update
  • Support for gRPC-aware proxy deployed between Gitaly and rest of GitLab
  • Test coverage project CI/CD setting
  • Vulnerability Check
  • `CI_BUILD_*` predefined variables
  • `fixup!` commit messages setting draft status of associated Merge Request
  • `projectFingerprint` in `PipelineSecurityReportFinding` GraphQL
  • `started` iterations API field
  • Removals and breaking changes

    The complete list of all removed features can be viewed in the GitLab documentation.

    Important notes on upgrading to GitLab 14.8

    • Reminder: GitLab 14.6 introduced a feature flag (ci_destroy_all_expired_service), which controls the service that removes expired CI/CD artifacts. This feature flag is currently disabled by default, so expired artifacts are not removed.

      We expect to enable this feature flag in a future milestone, which will allow the service to start removing expired artifacts again. For more information, see the relevant issue.

    • For users using the kube-state-metrics component, GitLab 14.8 includes an upgrade to Prometheus Helm chart from 11.16.9 to 15.0.4 that may require a manual step. Upgrading from 11.16.9 to 15.0.4 changes the selector labels used on the kube-state-metrics Deployment, which is disabled by default (prometheus.kubeStateMetrics.enabled=false). If this error message is encountered, meaning prometheus.kubeStateMetrics.enabled=true, then upgrading requires an additional step.
    • For users of Redis 6.2 and using hostnames instead of IP addresses for announcement, we are adding an experimental config option for Redis hostname announcing.


    Please check out the changelog to see all the named changes:


    If you are setting up a new GitLab installation please see the download GitLab page.


    Check out our update page.


    We'd love to hear your thoughts! Visit the GitLab Forum GitLab Forum and let us know if you have questions about the release.

    GitLab Subscription Plans
    • Free: Free-forever features for individual users
    • Premium: Enhance team productivity and coordination
    • Ultimate: Organization wide security, compliance, and planning

    Try all GitLab features - free for 30 days

    Cover image licensed under Unsplash License

    Try all GitLab features - free for 30 days

    GitLab is more than just source code management or CI/CD. It is a full software development lifecycle & DevOps tool in a single application.

    Try GitLab Free
    Open in Web IDE View source