Our security dashboards provide quick insight and visibility of potential vulnerabilities detected by our various Secure scanners. Engineering and security team members can quickly review, triage, and create issues for remediating vulnerabilities. Sometimes, vulnerabilities do not need to have further action taken and can be dismissed. For projects with multiple such findings, dismissing each individually can be time consuming.
We’re excited to announce new functionality on the security dashboards that improves the efficiency of vulnerability management. You can now quickly select multiple vulnerability findings and dismiss them all at once.
From a pipeline, project, group, or instance security dashboard, select all vulnerabilities on the screen with a single click or choose specific ones to then dismiss with a pre-set reason. For even faster triaging, use the existing dashboard filters to look at only specific vulnerability types where dismissable findings are likely to appear.
GitLab wants to make it easy for users to have modern secrets management. We are now offering users the ability to install Vault within a Kubernetes cluster as part of the GitLab CI managed application process. This will support the secure management of keys, tokens, and other secrets at the project level in a Helm chart installation.
GitLab already supports project-level deploy tokens. Now, we’ve added support for deploy tokens at the group level to make it easier to configure groups of projects. This will make sharing secrets between projects much more convenient and help in use cases such as: users deploying many projects to one Kubernetes cluster where different secrets need to be created per project. Creating a group level token allows users to set one shared secret for the entire cluster.
GitLab Releases are a one stop place for all the contents of a release. With the new Release Progress View introduced in GitLab 12.9, you will be able to easily answer the questions many release and build managers are spending time manually collecting. In a single look on the Release page, you can see the number of open, closed, and in-progress public issues that are associated with the milestones of the Release. A convenient percentage progress bar will also give you a quick update on how your release is progressing.
Beginning with this release, child pipelines can now be started using a dynamically
.gitlab-ci.yml. Using this approach, you can generate child
pipelines that reflect runtime analysis of what’s changed or other criteria (for example, to
build a matrix of targets and architectures).
This addition will open up a whole new set of use cases for this feature, while helping keep configuration simple. We can’t wait to see what you build with it!
Many users want to deploy to AWS using GitLab CI/CD. In order to help deploy to Elastic Container Service (ECS), we have created a template that shows you how to get started.
Users can include the template in their configuration, specify a few variables, and their application will be deployed and ready to go in no time.
Before GitLab 12.9, users trying to roll out a pipeline could encounter a situation where an older and delayed pipeline would deploy after a newer deployment and override it. Now, forward deployments provide the option to ensure that when a pipeline runs, it is verified to be the most recent deployment and makes sure that an older pipeline doesn’t override a newer one.
We’re pleased to announce new controls to manage your Web Application Firewall (WAF)! You can now easily turn your WAF on or off globally on your project’s Operations -> Kubernetes page.
We’re pleased to announce WAF Statistics Reporting! You can now see data on both total and blocked traffic, allowing you to more easily determine how to configure, tune, and evaluate the Web Application Firewall.
WAF statistics will appear on a new Threat Monitoring page under the Security & Compliance menu item. By default, this data covers a 30 day period.
Review apps currently require a static URL to be used as the CI/CD variable
CI_ENVIRONMENT_SLUG. In many use cases, though, this environment variable is dynamic instead of static. For example, when using AWS, a user may want to use the environment name based on the stage, which may not be known before the deployment.
In 12.9, we’ve introduced a new report artifact,
dotenv. The artifact can be passed between jobs, providing truly dynamic URL support for Review Apps. This unlocks the ability to use Review Apps in dynamic environments, such as native cloud deployments.
Previously in Ultimate, group-level Roadmaps are now available for Premium! Tracking the state of your work is key to delivering value on time. Visualize your epics across a timeline and see when they are scheduled to be completed.
Knowing the status of work in flight is critical. Our Roadmap now helps you visualize progress by displaying the percentage of weight completed via a progress bar on displayed epics. Keep up to date with your critical projects and efforts with ease!
For many customers, GitLab is a business critical application because an outage would prevent developers from being productive, and obstruct the deployment of new features and fixes. To prevent outages, GitLab can be run in a highly available (HA) configuration. The currently documented HA configuration recommends using NFS. However, NFS significantly increases the latency of read and write operations, which severely impacts the performance of Git operations, particularly as the size of the repository grows.
Gitaly now offers experimental alpha support for high availability without using NFS. This feature should not be used in production! There are single points of failure, and unexpected data loss may occur. However, you may wish to start evaluating high availability for Gitaly in a test environment. Since January, we have successfully been testing on GitLab.com with a small number of projects.
High Availability for Gitaly is eventually consistent, implemented as an asynchronous replication queue, favoring availability over consistency. If an outage occurs on a primary Gitaly node before the replication queue has been drained, data loss will occur. In parallel we have begun investigating strong consistency to prevent such data loss scenarios.