Petes Linkedin Blog

GitLab is a complete DevSecOps platform and integrates a variety of different security analyzers for Static Application Security Testing (SAST) and Secret Detection that help developers find vulnerabilities as early as possible in the software development lifecycle. Since the tools GitLab integrates are very different in terms of their implementations and their technology stacks, SAST tools are wrapped in Docker images with sensible default configurations that target the majority of use-cases. However, GitLab users and organizations may want to enhance the capabilities of the scanners they use by adding more detection rules or by eliminating findings that they identified as false positives based on their particular application context. GitLab users and organizations may opt to implement a more specialized configuration that meets the demands of their project. Organizations may wish to manage their own security configurations by hosting them in a dedicated Git repository. This will ...

2021 has turned out to be another … interesting year, especially for those of us in the security industry. Like so many software companies in the business, much of our recent focus has shifted to collective, cross-organizational research efforts to identify, mitigate and help resolve the threat posed by the Log4j vulnerability (See our response , as well as our post where we detail how to use GitLab to detect Log4j vulnerabilities ). Thankfully though, 2021 was also focused on growing the Security department and adding additional teams and roles, bolstering enterprise SaaS security, reducing our threat landscape with improvements to supply chain security and APT threat protection, and fulfilling our mission of working to enable GitLab to succeed in the most secure way possible (see our vision and mission statements ). We achieved impressive results through expansion of our security third-party certification and self-attestation portfolio, contribution of GitLab and customer impacting ...

We are working to make the GitLab Chart and the GitLab Operator support Kubernetes 1.22, which requires updating the NGINX Ingress Controller used within the Chart and Operator. This update requires that we drop support for versions of Kubernetes prior to 1.19 if using the in-chart NGINX Ingress Controller. Users that still require support for Kubernetes 1.18 and prior releases will only be able to deploy up to Chart version 5.5.x. More details on the changes GitLab uses a forked version of the community-supported ingress-nginx Chart to expose the GitLab components via Ingresses. Supporting Kubernetes 1.22 requires updating the included NGINX Ingress Controller to version 1.0.4 in order to support the networking.k8s.io/v1 API in Kubernetes 1.22. The previous networking API (networking.k8s.io/v1beta1) has been deprecated since Kubernetes 1.19 and removed in Kubernetes 1.22. As a result of the upgrade, we are bound to the breaking change of NGINX Ingress Controller, removing suppo...

Around this time a few years ago, I had the opportunity to bring more consistency and rigor to GitLab’s product icons, and ever since then I’ve been working through the next iteration. You can read more about the previous effort in this post, GitLab Iconography: MVC meets visual design . Today, though, the next iteration is here, and I’d like to briefly share a bit of what went into it. First up, a little housekeeping. Changes to a user interface (UI) can be highly subjective, and while I don’t think preference will or should ever be eliminated, it shouldn’t be the driving factor for change. To that end, we always take a thoughtful approach to any change in the GitLab UI. And in the spirit of iteration, I think my colleague, Tim Noah, put it best when he said that we’re privileged to “work on the ink that never dries.” This isn’t the first iteration, and it certainly won't be the last. Icons can be better While there’s more nuance than I can unpack here, at a high level the prob...

The Great Resignation is upon us. Turnover rates in the U.S. continued to reach historic highs in October 2021, with more than 4.2 million people quitting their jobs that month, according to the Bureau of Labor Statistics . While this Great Resignation can be attributed to a number of factors, it’s clear that remote and flexible work is high on the list for knowledge workers globally.  In fact, in GitLab’s 2021 Remote Work Report , 52% of remote workers said they would consider leaving their co-located company for a remote role. If remote work was suddenly no longer an option, one in three respondents would quit their job.  Whether you’re a job seeker looking for your first remote role or an employer hoping to embrace remote work to attract and retain the most talented people in this new era of work, here are a few things to keep in mind. Job seekers: What to look for when considering a remote job Working at GitLab Commit London 2019 In a job market that is stacked in y...

Note: Out of an abundance of caution, we encourage users who are using older version of GitLab SAST and Dependency Scanning to update to the latest versions. You can find more information and recommended actions in this blog post . Any customer leveraging the recommended includes for GitLab SAST has automatically received the new patched versions released Dec 13, 2021. In light of the recently discovered log4j vulnerabilities, we would like to demonstrate how GitLab can be used to assess and remediate the log4j vulnerability as well as other security vulnerabilities that may exist in your projects. The solutions shared here are: Dependency Scanning (Ultimate) Container Scanning (Ultimate) Cluster image scanning (Ultimate) Advanced Search (Premium) Free users wishing to access Premium and Ultimate features can do so by signing up for a free trial of GitLab. Use GitLab dependency scanning to detect and mitigate log4j vulnerabilities Dependency scanning uses Gemnasium, whic...

We want to share the actions we’ve taken in response to the Log4j remote code execution vulnerabilities CVE-2021-44228 and CVE-2021-45046 . Upon becoming aware of the vulnerabilities, we immediately mobilized our Security and Engineering teams to determine usage of this software component and its potential impact within our product, across our company and within our third party software landscape. Our teams have continued to investigate and monitor the situation over the past few days and It has since become known that the following third-party software dependencies used in our SAST and Dependency Scanning features include the vulnerable Log4j libraries: PMD OSS (used in SAST) Spotbugs (used in SAST) Gemnasium-Maven (used in Dependency Scanning) At this time, no malicious activity, exploitation, or indicators of compromise have been identified on GitLab.com. Actions we have taken to address the Log4j vulnerabilities We have confirmed our DAST analyzer is not using a vulnerabl...