GitLab 12.6 released with Security Scorecard and Release Evidence
GitLab 12.6 released with Security Scorecard, Release Evidence, Conan C/C++ repository, and much more!
A common challenge many development leaders face is having visibility into the overall application security and compliance status of their projects. This month's GitLab release helps you more efficiently monitor the application security and release compliance of your projects.
Security Visibility with Project Security Status
With GitLab 12.6, a new Project Security Status panel shows how projects are ranked according to their security profile. This makes it easier for development leaders to quickly understand which projects may have greater risk and therefore might warrant additional attention to address specific issues.
Streamline Audits with Release Evidence
Almost every enterprise development team is expected to document and demonstrate that each release complies with their organization’s policies, procedures, and controls. Often it means they have a manual processes to save the documentation so that future audits can review the compliance evidence. GitLab 12.6 makes audits and compliance much easier, with a release evidence file in the form of a JSON object that includes links to the milestones and issues that were included in the release, which can help to streamline future audits.
Efficiently Manage and Share C/C++ Resources
Many teams are actively developing new high performance applications in C and C++ and they need the ability to easily store and manage the compiled files and binaries from their projects. GitLab 12.6 now helps teams writing code in C and C++ to manage and share both privately and publicly the binaries from their projects with the popular Conan repository built into GitLab. They can now benefit from having source code, automated GitLab CI pipelines and the resulting packages in the same application which will help improve their overall efficiency and velocity.
We’re excited to announce a new “security grades” feature in Group
Security Dashboards. In addition to the existing vulnerabilities list
and history, this new panel on the Group Security Dashboard lets you
know which projects are most affected/at risk so you can go right to the
projects that need the most immediate attention.
The severity of any detected vulnerabilities on a project is used to
create a simple A through F letter grade. Projects are grouped by
grade, so you can easily see which have no unresolved vulnerabilities
(grade A) through to those with at least 1 critical (grade F).
For any development organization, having an easy and secure way to
manage dependencies is critical. Package management tools, such as Conan
for C/C++ developers, provide a standardized way to share and version
control these libraries across projects.
In GitLab 12.6, we are proud to offer Conan repositories built directly
into GitLab. Developers can now publish their packaged libraries to
their project’s Conan repository. Simply set the Conan remote to the
GitLab Package Registry and start uploading, installing, and deleting
packages today.
Planning and managing a release can be complicated and being able to quickly
find the related issues and merge requests makes it easier for teams to manage their work.
In 12.6, we have added the capability to filter issues and merge requests by
Release name. This will help find those items associated with a specific
Release.
When development teams release code changes in many organizations, they are required
to document the proof that they complied with the organization’s processes and policies
in their SDLC. Typically, this can be time consuming and inefficient. In 12.6, GitLab Releases
now have a new Evidence collection entry in which you can find a snapshot of the Release’s
metadata in JSON format. This snapshot can be leveraged as a chain of custody to support review
and compliance processes, such as audits.
Squash-and-Merge
allows you to combine all your merge request’s commits into one so you
retain a clean history in the default branch while preserving the
entire commit history in the merge request. In this release, we
added squash support to Merge Trains, which allows running a build
on the result of the merged code prior to merging, as a way to keep
master green. The combination of these two features will ensure that
master is always green while attaining a consolidated commit history.
We are excited to announce a new ability to view the Secure scanners.
You will see a new Configuration option under the Security and
Compliance section on the left navigation. This UI will show you which
security scans are available, what scans have been configured, and
provide clear links to the relevant scanner documentation.
Note: as this is the initial
MVC
of this new feature, there currently is no advanced configuration, so
you cannot disable or enable the scans from this screen.
Circuit by Unify is a collaboration and
communication system used by many organizations. Similar to other notification
integrations within GitLab, you can now configure webhooks to send
selected notifications to a Circuit conversation. Notifications link back to your
GitLab project, eliminating the need to context switch between an email client
in order to keep up to date with GitLab activity.
Organizations need a way to secure their GitLab instances that aligns
with their internal policies and procedures. Part of securing
GitLab is enforcing a
password policy. GitLab recently updated its own internal password
policy
guidelines
based on NIST SP
800-63B. In this
special publication, NIST advises on leveraging password length and
complexity, but does not recommend password rotation or even requiring
specific complexity rules (e.g. a specific number of special
characters).
Using NIST’s guidance, GitLab is introducing a new setting within the
Admin Area to specify a minimum password length that applies only to
new passwords. This means any new account being created or any password
being changed will be required to meet this minimum length requirement.
By enabling customers to define a minimum password length, GitLab
environments can become more secure and organizations can manage this
policy across an instance for reassurance that passwords are compliant
with internal policies.
Security-minded organizations have historically used regular rotation of
credentials to limit the amount of time an attacker has access to a
system through a compromised secret. While guidelines from organizations
like NIST no longer
recommend periodic rotation, we’re adding the ability to enforce regular
rotation of personal access
tokens
due to their inherent lack of 2FA protection, customer demand, and
importance in certain compliance frameworks (e.g.
PCI).
With this change, an instance administrator can configure a maximum
lifetime for generated personal access tokens. Applying a limit will
expire existing tokens, which must be regenerated and adhere to the
newly applied expiration requirement. After a token’s expiration date
has passed, it must be regenerated.
Currently, deleting a project in GitLab through the UI or API
is immediate, irreversible, and unrecoverable without restoring from a backup. This has the potential to result
in unintentional data loss, which is a worst-case scenario for the team.
To reduce this risk, GitLab 12.6 introduces soft deletion for projects. Instead of immediate removal of the project
or group, the resource will be marked for deletion and removed after a configurable soft deletion time-frame. While the
default time-frame is 7 days, instances wishing to retain immediate deletion can set this to 0.
Mentioning a group with a large number of members can quickly lead to a
high volume of unwanted notifications. To avoid this, you can now enable
a group-level setting to prevent members from receiving notifications
when the group is mentioned in an issue or merge request.
Forking workflows makes it easy to contribute to any project by creating
a copy of the upstream project to work on before opening a merge request
to merge your changes into the upstream project. For popular projects,
the server-side storage requirements needed for thousands of copies
accumulate quickly and increase hosting costs.
In GitLab 12.1, we introduced fork de-duplication for public projects,
but many organizations missed out on the benefits because they primarily
use internal projects. In GitLab 12.6, creating a fork of public or
internal projects creates an object pool (if one doesn’t already exist)
and uses objects/info/alternates to reduce the storage requirements of
forks.
Before clicking Merge, if you make a final tiny fix by pushing or
applying a suggestion, the merge button is disabled until you reload the
page. This slows down the final stages of review when applying the final
fixes. In GitLab 12.6, the merge request widget is now updated in
real-time so that you can merge immediately or when the pipeline
succeeds.
When using a mix of project & group variables, it can be confusing to
understand what group variables exist and how they may be related or
conflict with project level variables. We have improved this by now
showing the group (inherited) variables in the project variables page,
making it easy to see what variables are coming from where.
As part of the GitLab Package Registry, we provide an
API, to allow users to
view, download, and delete packages. However, until recently the API was
limited to a specific project, which prevented users from understanding
which packages exist at the group level.
In GitLab 12.6, we are excited to announce a new API endpoint that will
allow users to list all packages at the group level.
In GitLab 12.6, we are adding the capability to edit Release titles and
notes directly from the user interface, instead of using the GitLab API.
This provides a faster and more intuitive method to edit releases.
You can now define different userID targets for your feature flags per
environment. The value that is gained here is that with this combination
you can target different users on production than staging (or others)
which allows you total control on how, where and to whom your Feature
Flag will be toggled.
Re-using clusters across instances, groups, or projects can be time
consuming as operators must ensure that all related cluster resources
(such as namespaces, roles, bindings, etc.) are removed from the cluster
prior to linking it to a new entity. Often times, operators choose to
destroy a cluster and create a new one to avoid manual deletion of
resources.
GitLab now provides the ability to remove all the related cluster
resources upon removal, making it fast and easy to re-use clusters
elsewhere.
Auto DevOps’ Auto-Deploy now allows for bulk configuration of its Helm
chart values. By simply adding a .gitlab/auto-deploy-values.yaml file
to your project, Auto DevOps will automatically detect it and use its
values for deployment. This eliminates the need to create multiple
HELM_UPGRADE_EXTRA_ARGS environment variables for your project and has
the added benefit of version control.
When creating a Kubernetes cluster via GitLab’s GKE integration, users
can now optionally enable “Cloud Run on Anthos” with a single click. GKE
will automatically provision the cluster with Knative serving, Istio,
and HTTP load balancing, and Cloud Run will take care of keeping the
cluster upgraded. When installed, users can continue to take advantage
of the features offered by GitLab
Serverless
to deploy Knative services with minimal configuration.
Note: We announced Cloud Run for Anthos support in GitLab 12.4, however
we had to switch it off later due to compatibility issues. We’ve been
working hard to ship a future-proof integration.
Starting with GitLab 12.6, when you install Knative as a GitLab Managed App, version 0.9 will be installed. This is a major upgrade in the life of Knative. Knative Serving
has received its final v1 API endpoints and is considered to be production ready, but the beta and alpha
endpoints are still available. Given the stable API, this upgrade provides some level of forward-compatibility too.
You’ve been there. You are troubleshooting an error you found in your
application and have to frequently jump back and forth between searches
through your error list. Starting in GitLab 12.6, you’ll be able to
quickly select recent searches when filtering errors.
Errors are often plentiful, noisy, and challenging to dig through to
find the important ones which are impacting your users. Starting in
GitLab 12.6, as you view a list of Sentry errors in GitLab, you’ll be
able to sort those errors based on frequency and when an error was last
and first seen.
If you are using PHP in your project, you can now use our License
Compliance
feature. Please note this is at the experimental support level. We
added support for PHP, specifically focusing on composer-based projects
(using composer.lock).
Projects that have dependencies that are hosted in a private repository
now have a way of propagating authentication credentials for the private
repository into the SAST container to have them used by the analyzing
command.
To assist users in troubleshooting CI integrations, we’ve added a log of
recent events to the integration configuration pages. This log is
available on the integrations settings pages for Jenkins, Packagist,
Team City, DroneCI, Buildkite, and Bamboo. This new section lists the
events that have triggered this integration in the last two days.
This is particularly valuable when you are trying to troubleshoot a
failing integration, as previously there was no place in the UI directly where these
errors were displayed. Now, you’ll have easy access to understand what
has failed (or is currently working!) and why.
In order to reduce the memory requirements of GitLab, we are migrating to
Puma from Unicorn.
Puma supports multi-threading, which can reduce the memory footprint of
GitLab by about 30%.
There are two ways to gain access to a private project or group: a)
being directly added to that specific project or group or b) inheriting
a role from a parent
group.
In GitLab 12.6, we’re making it easier to understand the source of a
user’s membership by allowing filtering of the Members table
specifically for direct members or inherited members.
As your GitLab self-managed instance grows, so too does your need for
compliance
controls.
As more users, groups, subgroups, and projects are added, your instance becomes inherently more complex. You need visibility into who has access to your instance in an aggregate view in order to manage your instance’s risks and compliance.
To support customers in this effort, we’ve introduced an
MVC
for an inventory of PAT and SSH credentials. This view provides
important details to administrators, such as the owner, type, and scope
of each credential. It will also show when a credential is set to expire
and when it was last used.
As we invest further in analytics in GitLab, our features should align with commonly used
terms. Conversational development is a useful concept, but GitLab is built around the
language of DevOps.
Directly referencing this term is especially helpful for organizations looking to track
their adoption of DevOps best practices. We plan on
iterating on this feature further, but
a first important step is a name change to reflect where we’re going.
The OpenAPI (previously known as Swagger) Specification is a popular
standard for defining RESTful interfaces. However, reading the YAML
source can be difficult. In GitLab 12.6, when viewing an openapi.yml
file (or another supported filename), a rendered preview of the
specification will be shown using the same interface as Swagger.
Merge Requests are where source code is reviewed, tested, and discussed,
but they can become unwieldy. Together, merge request descriptions,
pipelines, and security scanning results often push the navigation tabs
far down the page making them hard to find and difficult to access.
In GitLab 12.6, the merge request navigation is now above the
description, making it fast and easy to jump directly to the changes.
Additionally, the description and widgets are now displayed on the
Overview tab, providing improved focus and navigation throughout the
merge request. Please share your feedback
here.
Forking workflows makes it easy to contribute to any project by creating a copy of the upstream project to work on before opening a merge request to merge your changes into the upstream project.
Previously, when the visibility of the root project in a fork network was changed to be restricted, the visibility of all the forks would be restricted. This could result in all forks of a public project suddenly becoming private if the root project was made private.
In GitLab 12.6, instead of changing the visibility of all projects, the root project is simply removed from the fork network leaving all other projects unmodified. This is equivalent to the root project being deleted.
We’re also releasing GitLab Runner 12.6 today! GitLab Runner is the open source project
that is used to run your CI/CD jobs and send the results back to GitLab.
We have added the ability to specify the path of the .gitlab-ci.yml to
an arbitrary URL, which allows you to store CI configurations in a
repository other than the one being built. This can be very helpful for
processing many repos the same way by pointing all of them to the same
external .gitlab-ci.yml file. Efficiency is gained by having only one
CI configuration file to update instead of maintaining individual
configurations in each repository. Users that have a service that
generates the configuration file dynamically would also benefit.
This also makes it possible to protect configurations from unauthorized
changes as the file can be hosted in a project with more fine-grained
access control. We have updated our documentation to make it clear how
to set this up.
In GitLab 12.6, we are very excited to announce that the NPM Registry
now supports installing package dependencies. Until recently, running
npm install would not work if the version was not included in the
command. In addition, the command would not support installing the
packages’ dependencies. This was due to us not supporting the required
NPM metadata, such as dependencies or tags.
Interacting with a major cloud provider such as AWS, Azure, or GCP is a core component of many delivery pipelines. But before you can automate your cloud interactions, you need to have an environment set up with the appropriate tools. Previously this was something you had to manage on our own, but starting in 12.6, GitLab will provide an official AWS Docker image that will allow you to run aws commands from your CI/CD pipelines. You can access a variety of AWS services using a Docker image that is maintained and kept up-to-date by GitLab.
When users choose Merge Immediately for their merge request, this
delays all the merge requests in the Merge Train. Users were
unintentionally doing this, unaware of the negative effect caused to the
rest of the merge requests. Although we still allow urgent merge
requests to skip the line, we added a warning as another layer of
protection by explaining that this action will negatively impact others.
When you use GitLab’s Kubernetes integration, it automatically creates a
namespace to serve as a deploy target for GitLab CI/CD. This makes it
easy to get started with Kubernetes. However, if you already have a
cluster with an existing set of namespaces, more than likely you will
want to designate one of those existing namespaces as a GitLab deploy
target.
Now with GitLab 12.6, you are able to specify a custom namespace for
each CI environment in your .gitlab-ci.yml file allowing you to deploy
to namespaces that existed before you connected your Kubernetes cluster
to GitLab. Initially, this feature is only available for non-managed
clusters but does support dynamic environments (e.g. for use in review
apps).
We often need to carry out actions on Kubernetes clusters directly, for
example while troubleshooting or fine tuning. Making changes to
Kubernetes resources directly in the cluster can put GitLab out of sync
with the cluster so it won’t recreate resources because it assumes they
already exist.
Starting with GitLab 12.6, the Kubernetes integration will offer the
option to clear the local cache of namespace and service accounts,
allowing the next CI job to re-create them when necessary.
Installing Kubernetes applications using GitLab CI
provides a great way to customize Helm charts prior to installation.
In order to make it easier to get started, we have added a
CI template
with all the currently supported applications. In addition to this template, we
have created an example cluster-management project
containing all the necessary items required to get started. Simply import and mirror
this project to get all the latest supported apps.
Triaging errors can be a manual and tedious process often completed by
multiple individuals on your team. One team member may determine the
Error is critical and go to create issues to fix the error. Starting in
GitLab 12.6, Errors provide a link to open issues directly within the Error detail page, eliminating any confusion about
whether an issue needs to be created.
If an issue doesn’t exist, you can now quickly create a GitLab issue from an generated Error when viewing that Error’s detail page.
If you’re a user of GitLab’s Error Tracking features, you value the
ability to integrate with Sentry, the most popular open-source error
tracking tool. Starting in GitLab 12.6, if you are unable to utilize a
Sentry project on Sentry.io, you can deploy Sentry directly to a
Kubernetes Cluster attached to your project or group. This will make it
much quicker to get started with integrated error tracking in GitLab.
Previously, there wasn’t an easy way to navigate directly to your pods’
logs view. In order to get to them you had to navigate to your project’s Environments tab
underneath Operations, select the desired environment, and click the
relevant pod. Now, with GitLab 12.6, viewing Pod Logs is easier than
ever! Simply click on the Pod Logs tab underneath Operations.
If your Python dependencies are stored in a file other than the regular
requirements.txt, with GitLab 12.6, you can now set the requirements
file with the PIP_REQUIREMENTS_FILE variable.
With GitLab 12.6, we have added support for Scala with the sbt package manager
in Dependency Scanning. You are now able to scan your Scala projects for potential vulnerabilities.
Group Webhooks are now editable! Previously, it was only possible to
create and delete them, so making a change to a webhook required you to
delete the webhook and start over. This addition adds the ability to
edit these in the UI, saving you time and effort when setting up your
webhooks.
When a user has GitLab integrated with Jira, comments are posted in Jira
when activity happens in GitLab. This addition allows a user to disable
those comments from the configuration page on a per-integration basis.
This is valuable for many users who don’t want to see the comments, but
still want to automatically link their Jira issues to their GitLab
projects. Additionally, some users have noted use cases where there are
Jira users who should not have visibility of activity on the
repository for confidentiality reasons. Having more fine-grained control
over what content is posted to these comments is valuable for both of
these cases.
When deploying GitLab in Kubernetes, the minimum supported version of
Kubernetes is now 1.12. Kubernetes 1.11 is no longer maintained
upstream,
and has recently been dropped by popular container management services
such as GKE and EKS. GitLab uses Kubernetes 1.13 by default.
Deprecated variables and argument for manual configurations of .gitlab-ci.yml when using Secure features
As previously announced in Release Post
12.0,
if you have manually configured .gitlab-ci.yml:
The command line argument --auth-first-page was removed in issue 7182 and is no longer supported and you need to remove it.
The DEP_SCAN_DISABLE_REMOTE_CHECKS flag variable for Dependency Scanning was removed in issue 9953 and is no longer supported and you need to remove it.
The sast_container value in the GITLAB_FEATURES pre-defined environment variable was removed in issue 8217 and is no longer supported and you need to change it to container_scanning instead.
You also need to verify that you are using the new report syntax, since all Security scanning features are dependent on the reports being available in the expected location. If you do not update to the new report syntax, they will stop working.
If you use the vendored templates instead of manually defining the jobs, you don’t need to do anything.
As we continue to improve and enhance our integration with Elasticsearch, support for
Elasticsearch 5.6.x will end with the release of GitLab 12.7. Elasticsearch 5.6 reached its
end of life with the release of Elasticsearch 7.x. Updated
version requirements
for GitLab 12.7 will include support for only Elasticsearch 6.x.
At this time there is no timeline for support of Elasticsearch 7.x with GitLab; you can follow
this issue for updates. GitLab recommends
self-managed customers upgrade to ElasticSearch 6.x.
In GitLab Runner 13.0 we will remove the backported os.Expand() from Go
v1.10.8. This backport was needed to include a change in behavior
introduced in Go v1.11. Additional details can be found in issue #4915.
In GitLab 11.11, we deprecated the use of Windows Batch executor for the
GitLab Runner. Support for Windows Batch will be removed in GitLab 13.0.
Additional details can be found in issue #6099
Deprecate Ruby string interpolation on Prometheus queries
We plan to remove the Ruby string interpolation (curly braces with a
leading percent) in the next major version (GitLab 13.0) and replace it
with liquid template
support. If you are
using the following format 'string_%{variable}_string' on your
Prometheus queries to pass parameters, you’ll need to replace it with
'string_{{variable}}_string'.
Gitlab 13.0 will drop support for InfluxDB self monitoring metrics
We plan to remove the GitLab self monitoring metrics collected by
InfluxDB in the next major version (GitLab 13.0).
Prometheus
is our official self monitoring tool for GitLab. It is installed by
default on every GitLab instance and is collecting the same metrics as
InfluxDB.
Planned removal of PostgreSQL 9.6 and 10.x in GitLab 13.0
To take advantage of improved performance and functionality in PostgreSQL 11 such as
partitioning, we
plan to require PostgreSQL versions 11 and
12 in GitLab 13.x. To accomplish this, we will
be introducing support for PostgreSQL 11 in an upcoming release of GitLab 12.x while maintaining support for 9.6 and 10.x.
With the arrival of GitLab 13.0, PostgreSQL 11 will be required.
By minimally requiring PostgreSQL 11, we are able to leverage the new features introduced, without
the overhead of maintaining multiple code paths. Going forward, we will be maintaining a yearly
cadence of PostgreSQL upgrades, with support for the second and third most recent versions as soon as
we are able to add them. We welcome your feedback on the proposed removals. Please comment in the
Move to PG 11 and 12 epic.
Geo settings have
moved to Admin Area
> Geo > Settings. The old location (Admin Area > Settings > Geo)
will remain available with automatic redirection until GitLab 13.0.
As part of our architecture updates for GitLab pages, Pages will be using an
API instead of using disk-database access. This has already been done on
GitLab.com.
To help with the larger migrations, we have introduced background migrations
(Sidekiq jobs that will run asynchronously) for this release. For
GitLab.com, these migrations took around 36 hours to complete, and no side
effects were expected nor introduced.
To find the approximate time it will take to complete these migrations on
your instance, run the following command from a Rails console:
(Project.count.to_f / 300_000).ceil. To check the status of the background
migrations, run: Sidekiq::Queue.new('background_migration').size.
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