GitLab 14.3 premiers proprietary SAST engine, adds flexibility to pipelining

GitLab 14.3

The monthly GitLab update is here, adding some bits to make pipelines more flexible while looking to improve security and access management for those willing to pay for v14.3 of the DevOps platform.

Organisations on the Ultimate subscription, for instance, are now able to manage secret detection scans and dynamic application security testing (DAST) via execution policies, making scans independent from the content of the .gitlab-ci.yml configuration file. GitLab 14.3 is also the first release to make use of the company’s new proprietary static application security testing (SAST) engine as part of the Ultimate offering. 

According to the release blog, the engine is meant to “eliminate vulnerabilities that may have been falsely reported by other integrated security tools” through use of different program representations and a “novel pattern extraction language”. Long-term goals for the tool include better integration of security testing into the software development lifecycle and improvement of various testing types.

To improve the scalability of a setup, Ultimate and Premium customers can now allow Agents access to more than one group. Teams don’t have to register agents for all projects under an authorised group anymore since they are all automatically able to use the same agent for cluster access. Other enhancements available to paying subscribers include group-level permissions for protected environments, and additional recordings of audit events when changing settings for protected branches or merge request approvals.

However, GitLab 14.3 also brings some more flexibility to CI/CD pipelines. The include keyword used to make external configurations part of the pipeline can be combined with new rules conditions, allowing teams to define in which case a YAML should be included. Once defined, rules can be reused in different jobs via !reference tags. Another change meant to simplify pipeline writing a little is the capability to use variables inside other variables, and there’s an option to filter pipelines by source for a better overview. 

Teams making use of GitLab’s Dependency Proxy have gained the ability to retrieve details about cached container images via a GraphQL API which was introduced as part of the release. Details about other interesting additions, ranging from Kubernetes 1.20 support to user GPG key displays and a multimedia preview in the Wiki editor, can be found in the release post.

GitLab Runner, the component helping GitLab CI/CD to run jobs in a pipeline, got an update as well and now includes a feature flag to have the shell executor clean up artifacts in the build directory. It also no longer considers all sorts of failed Docker image pulls to be runner system failures, but makes a distinction between system and scripting errors.

The new release comes just a couple of days after the company filed for an Initial Public Offering, which was already expected for 2020, but had been postponed — presumably for pandemic reasons.