GitLab receives update along with security scan policies

Another worthy improvement is to the GitLab Kubernetes agent. This provides a secure connection between a Kubernetes cluster and GitLab. Until now, you could only push to a cluster from the same project where the Kubernetes Agent was registered using the CI/CD Tunnel. In GitLab 14.3, the Agent can be authorized to access entire groups, meaning that every project under the authorized group has access to the cluster without the need to register an agent for every project.

News

30, 09, 21

2 mins

The Git repository manager received improvements including project-level security scan execution policies and improved SAST to reduce Ruby false positives and provides issue-tracking, continuous integration, and deployment pipeline support.

The update adds group-level permissions for protected environments and group access for the GitLab Kubernetes Agent.

The project level security policy is described by the developers as being the first iterative step toward their vision of bringing unified security policies to GitLab. Users can now require DAST and secret detection scans to run on a regular schedule or as part of project CI pipelines. This can be used by security teams to separately manage these scan requirements without developers changing the configuration.

The second change of note is the ability to set and use group-level permissions for protected environments. This can be used to set permissions based on the deployment level, so that deployments can be locked down for higher-tiers such as production environments, while still letting developers test and change individual projects.

GitLab Kubernetes Agent CI tunnel at the group level – demo

The GitLab team says that GitLab’s SAST has until now used over a dozen open-source static analysis security analyzers. The vulnerabilities they can identify range from basic regex pattern matching to abstract syntax tree parsing which can lead to issues with false positives. Developers could already dismiss these false positives, but the improvements mean this will now be automated. This first version of GitLab’s proprietary static application security testing engine has been developed in-house and maintained by GitLab’s Static Analysis and Vulnerability Research groups. Initially, this tool is focused on Ruby and Rails to help reduce false positives, but will be extended in future releases.