GitLab 14.4 released with Scheduled DAST scans and Integrated error tracking
GitLab 14.4 released with Scheduled on-demand DAST scans, Integrated error tracking, Remote Repositories for GitLab in Visual Studio Code, DevOps Adoption trend graph, GA for GitLab Operator and much more!
Ethan leapt in and offered to contribute remote repository support in VS Code for GitLab hosted projects. This effort was no small feat and consisted of not one, not two, three or four merge requests, but five total contributions to add this feature.
Ethan has also been a consistent contributor in both issues and other merge requests to GitLab Workflow for VS Code helping to both contribute code and respond to users with questions and issues. Ethan even picked up a bug fix after shipping remote repositories that a user reported so that the feature worked well for all.
GitLab’s Dynamic Application Security Testing (DAST) now supports scheduled on-demand scans. Previously, on-demand DAST scans could only be manually triggered, which limited the usability to scans that you wanted to run immediately. With this new scheduler, you can set a DAST scan to run either once at a specific time in the future, or on a recurring basis. If adding DAST to your pipelines is not an option for your organization, or if the security or compliance regulations for your area require a scan to be scheduled, this feature provides an easy way to create a scheduled scan to meet your needs. The scan can be associated with the default branch, which allows for the results to show on the Secure Dashboard and Vulnerability list. Combined with the scan and site profiles, the scheduled on-demand scans give you quick and easy access to DAST results for your application or API, on a schedule that works for your development and security teams.
When working in your editor you may need to refer to another project or upstream library for additional information. When you don’t have that project already cloned locally, you’re forced to either leave your editor and browse the project on GitLab, or locate and then clone the project so you can browse it in your editor. Both of those tasks break your current context, introduce delays, and can take you to a less familiar interface for working with code.
GitLab Workflow version 3.33.0 provides an option to open a remote repository. Open the command palette and use the GitLab: Open Remote Repository command to find and then open a project.
Opening a remote repository allows you to browse a read-only version of a project in your familiar VS Code environment. You can then quickly find the information you’re looking for, compare an implementation, or copy a snippet you need.
Thanks to Ethan Reesor for the amazing work and numerous merge requests required in contributing this feature!
GitLab 14.4 is proud to announce the general availability of the GitLab Operator, with the ability to run production instances of GitLab on Kubernetes platforms, including Red Hat OpenShift. The GitLab Operator also automates day 2 operations such as upgrading components, application reconfiguration, and autoscaling. Check out the GitLab Operator installation documentation for additional information.
In GitLab 14.4, we added a new graph to group-level DevOps Adoption for trend over time. This graph shows you how groups adopt DevOps features over time and can give insights into how quickly groups are adopting additional DevOps processes. This is broken down by Dev, Sec, and Ops functionality.
Prior to GitLab 14.4, you could integrate with Sentry Error Tracking by supplying an endpoint for a Sentry backend (either self-deployed or in their cloud service). With Gitlab 14.4, you now have access to a Sentry-compatible backend built into your GitLab instance. This allows you to quickly instrument your apps so your errors show up directly in GitLab without the need for a separate Sentry instance.
As part of our effort to streamline our top-level navigation within projects, we have moved Requirements into the Issues menu. This move aligns with our vision to align our navigation to common tasks and reduce the number of top-level navigation items by grouping functionality under sub-menu items when possible.
The Slack integration in GitLab now has the option to create a notification when a new vulnerability is detected. This ensures that the right team members are notified and new vulnerabilities get the proper level of attention.
Value Stream Management for projects just got better. You can now sort the work items in a stage by time or name. We’ve also added pagination to make it easier to locate and display the issues you’re interested in.
Suggesting changes to a merge request makes code review faster and easier by quickly proposing changes and applying the given feedback at a click of a button. In GitLab 13.9, we made this experience even better by allowing users to specify a custom commit message for suggested changes to improve workflows that require custom commit messages. However this wasn’t available for batch suggestions, which meant users needed to either apply suggestions individually or resort to squashing all commits locally prior to merge.
You can now write a custom commit message when applying batch suggestions. This allows authors and contributors to accept suggestions and follow commit message best practices for their projects. It also helps to reduce the number of commits by applying all the suggestions as a single commit with the desired message. If no custom commit message is specified, the suggestion is committed with a default commit message.
We’re also releasing GitLab Runner 14.4 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.
In GitLab 13.12, we started rolling out this feature, limiting the number of runners registered to a group or project. As of 14.4, this feature is now fully enabled on GitLab.com and limits the number of registered runners to 1,000. For self-managed administrators, this means you can implement limits at the group and project level, which will help reduce the administrative overhead resulting from teams registering new runners while not removing inactive runners.
Setting a resource group in your CI/CD job enables you to prevent the same job from running concurrently when the same pipeline runs in parallel. This can happen if for example, you push multiple commits in very short intervals. Running multiple deployment scripts to the same infrastructure could harm your instance and leave it in a corrupted state in the worst case scenario. By default, the process mode of a resource group is set to unordered, which means that a job runs whenever it’s ready to run.
In GitLab 14.4, we added two more process modes that are useful when you want to enforce a specific execution order of the jobs: oldest_first and newest_first. By setting the process mode with one of these new options, the system will enforce the execution of jobs in FIFO (First in First Out) order, or LIFO (Last in First Out) order, respectively.
The current implementation of Secret Detection automatically resolves findings (marking them as fixed) for every secret detection scan that is run by diffing between pipeline executions. With the introduction of historic secret scanning in GitLab 13.0 we do not want to automatically resolve findings because this effectively erases secret vulnerabilities that are still present in the Git history.
This change in behavior will improve the usability of the historic secret detection while also providing more clear audit trails for normal secret detection and align the vulnerability management of secret detection findings with our other security scanners.
GitLab Static Analysis is comprised of a set of many security analyzers that the GitLab Static Analysis team actively manages, maintains, and updates. Below are the analyzer updates released during 14.4. These updates bring additional coverage, bug fixes, and improvements.
Semgrep updated to version 0.69.1 (MR, Changelog).
Reverted change to exclude minified files from the scan.
Flawfinder updated to version 2.14.5 (MR, Changelog).
pmd-apex updated to version 6.3.9 (MR, Changelog).
If you include the GitLab-managed vendored SAST template (SAST.gitlab-ci.yml), you do not need to do anything to receive these updates. However, if you override or customize your own CI template, you must update your CI configurations. If you want to remain on a specific version of any analyzer, you can now 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 template.
Grafana downgrade from 8.1.3 to 7.5.11. For more information, see the changes documentation.
Mattermost 5.39. Mattermost is an open source Slack alternative. Its newest release contains a low-level security fix and other improvements, such as improvements to collapsed reply threads.
Previously, usernames in SAML assertion attributes on GitLab.com were derived from the
user’s email address. Now the user’s GitLab.com username is used when the SAML response
includes a username or nickname attribute. This allows for more flexibility in defining GitLab usernames when using an Identity Provider.
DevOps Adoption just got better. You can now sort groups and subgroups in the DevOps Adoption table by column name, making it easier for you to locate the group you’re interested in.
Filter scoped labels with a wildcard to quickly find issues, epics, or merge requests that all share the same key from a set of scoped labels. You can also pair wildcard filtering with != (is not) to easily filter down items that do not have any label from a set of scoped labels. To filter with a wildcard, just append * after typing in your scoped label key (for example, label::*).
Now it’s even easier to take advantage of the powerful Web IDE and contribute to a project from your web browser. Simply press the . (dot) key on your keyboard to open the Web IDE with the current context loaded and ready to edit. Whether you’re navigating individual files in the repository or reviewing a merge request, this is a great way to start editing without taking your hand off the keyboard.
The CI_JOB_TOKEN CI/CD variable makes API calls more intuitive within CI/CD jobs, enabling advanced automation. For example, the token can be used with bot automation projects that run pipelines in other projects. The token is short-lived, but in an effort to make its usage even more secure we are adding a setting that lets you list the exact projects that can be accessed with your project’s CI job token. If the token is used to try to access other projects, it will be denied access to the API. In the bot automation example, it gives you additional control over the exact projects your bot will have access to and an added layer of security when using the CI_JOB_TOKEN CI/CD variable.
This setting is currently disabled by default to avoid impacting existing projects but we strongly recommend enabling it in all your existing projects.
You can use the GitLab Dependency Proxy to proxy and cache container images from Docker Hub for faster, more reliable builds. The problem is that, over time, your team may add a lot of items to the cache. This can result in higher storage costs.
You’ve been able to work around this by using the API to purge the entire cache. But that’s inefficient because you only want to remove old, stale items that are no longer in use. That’s why we’ve added cleanup policies for the Dependency Proxy. Now you can programmatically delete image tags from the cache that haven’t been recently used by your team.
Simply configure the number of days and all cached dependency proxy files that have not been pulled in that many days are deleted. We recommend 90 days as a good starting point. The cleanup policies for the Dependency Proxy can be set using the GitLab GraphQL API. We’re currently working on adding this setting to the user interface as well.
GitLab’s vulnerability management capabilities make it easy to triage and remediate security issues detected by our security scanning tools or from integrated 3rd-party tools. One limitation of this approach is that the vulnerability data can only come from the output of one of these tools. Organizations wishing to pull in other vulnerability source information currently do not have a simple option for doing so.
We are addressing this limitation with the introduction of new GraphQL properties for vulnerability object creation. You now have a way to programmatically add external vulnerability records directly to your projects. Combined with our existing GraphQL capabilities for vulnerability management, this opens up many new automation opportunities, such as syncing with an external bug bounty program or adding findings from security tools that may not be suitable for pipeline jobs, providing a more comprehensive view of a project’s security vulnerabilities.
In GitLab 13.12 we released Semgrep for Javascript, TypeScript, and Python. Today we’re expanding the Semgrep analyzer to support projects written in the Go language.
With 14.4, we’re updating our managed SAST.gitlab-ci.yml CI template to automatically run this new analyzer alongside our existing Go analyzer, GoSec. In a future release, we will fully disable GoSec, but for now it will work in unison with Semgrep. We’ve done work to deduplicate findings, so you should not notice any difference in findings. If you include our SAST.gitlab-ci.yml, you don’t need to do anything to start benefiting from the Semgrep Go analyzer. However, if you override or manage your own SAST CI configuration, you should update your CI configuration.
We are excited about the future of this transition to bring you fast and wide coverage Static Application Security Testing (SAST). We’ll continue to expand the Semgrep analyzer through new security detection rules as well as expanding coverage to other languages. We’ve created a feedback issue where you can share your experience with this transition or ask questions.
As a follow-up iteration to the Registration Features
program released in 14.1, we’ve added two more paid features for free GitLab self-managed users running GitLab EE. Simply register with GitLab and send us activity data through Service Ping, and you can enjoy these additional features for free:
In every release, we continue to make great strides improving the performance of GitLab. We’re committed to making every GitLab instance faster. This includes GitLab.com, an instance with over 1 million registered users!
In GitLab 14.4, we’re shipping performance improvements for issues, projects, milestones, and much more! Some improvements in GitLab 14.4 are:
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.4, we’re shipping usability improvements for issues, projects, milestones, and much more! We highlight the following changes in GitLab 14.4:
We want to hear from you
Enjoyed reading this blog post or have questions or feedback? Share your thoughts by creating a new topic in the GitLab community forum.
Share your feedback