Petes Linkedin Blog

At GitLab, dogfooding is part of our core value of results . Inspired by this principle, we use all GitLab security scanning tools available as part of our product within our organization to identify security vulnerabilities early in the development phase. One such scanning tool is the Dynamic Application Security Testing (DAST) scanner, which helps identify security vulnerabilities in web application deployments. The DAST scanner is a black-box testing tool that interacts with a web application like a user and tests for security vulnerabilities. We’ve since updated GitLab’s DAST CI job configuration to make use of the latest DAST analyzer features offered in DAST 2 . This blog post details how we configured DAST version 1 to work for our needs, our move to DAST 2 (along with details on our configs) and the benefits we’re seeing so far. Hint: Big wins in efficiency! How we made DAST 1 work for us My teammate Dennis Appelt blogged previously about how we configured DAST scans in...

Today we are releasing versions 14.4.1, 14.3.4, and 14.2.6 for GitLab Community Edition (CE) and Enterprise Edition (EE). These versions contain important security fixes, and we strongly recommend that all GitLab installations be upgraded to one of these versions immediately. GitLab releases patches for vulnerabilities in dedicated security releases. There are two types of security releases: a monthly, scheduled security release, released a week after the feature release (which deploys on the 22nd of each month), and ad-hoc security releases for critical vulnerabilities. For more information, you can visit our security FAQ . You can see all of our regular and security release blog posts here . In addition, the issues detailing each vulnerability are made public on our issue tracker 30 days after the release in which they were patched. We are dedicated to ensuring all aspects of GitLab that are exposed to customers or that host customer data are held to the highest security standard...

So your company has a DevOps team – great! – but are they elite performers or low performers? There’s a chasm of difference between the two, according to the State of DevOps 2021 report from DORA, the DevOps Research and Assessment team at Google. It’s the tipping point in how resilient, efficient and reliable your team is, and that’s directly tied to your ability to help your business be more competitive. (To be transparent, GitLab was one of the many sponsors of the report, and we’ve incorporated some of the DORA metrics within our DevOps Platform so you can compare your highest and lowest-performing teams and see how much of the DevOps lifecycle each one is embracing.) Bragging rights aside, a personal – and not insignificant – benefit of being on an elite DevOps team is that your company value , as well as your salary , would likely rise, as would your ability to be hired at a top-tier company. So what does it mean to be an elite DevOps team and what does it take to get there?...

As customers begin their journey with GitLab, they often start by moving their source code repositories to GitLab. The GitLab Professional Services team has been helping customers with large scale migrations for years and during this time have built a utility to automate the migration process - Congregate . To ensure we’re aligned with the GitLab values of transparency and collaboration, we’re making it available to customers and partners. As of today, Congregate has been moved to a source available disposition. For smaller customers this might not be too important because they can use GitLab import functionality to migrate themselves. But for customers moving hundreds or thousands of source code repositories and associated users to GitLab, this is a game changer. And perhaps most importantly, our growing team of channel services partners can now leverage Congregate functionality as they help customers move data. And for each contribution that partners or customers make back to C...

In the coming weeks, we are planning to roll out a new version of the Container Registry on GitLab.com. Prior to deploying this major update, we wanted to clearly communicate the planned changes, what to expect, and why we are excited about this update. If you have any questions or concerns, please don’t hesitate to comment in the epic . Context In milestone 8.8 , GitLab launched the MVC of the Container Registry. This feature integrated the Docker Distribution registry into GitLab so that any GitLab user could have a space to publish and share container images. But there was an inherent limitation with Docker Distribution as all metadata associated with a given image/tag was stored in the storage backend. This made using that metadata to build API features like storage usage visibility and sorting and filtering unfeasible. With the most recent update to the Container Registry, we’ve added a new metadata database that will store all of the metadata in Postgres instead of the storag...

Today, we are excited to announce the release of GitLab 14.4 with Scheduled DAST scans , Integrated error tracking inside GitLab without a Sentry instance , Remote Repositories for GitLab in Visual Studio Code , DevOps Adoption trend graph , GA for GitLab Operator and much more! These are just a few highlights from the 30+ improvements in this release. Read on to check out all of the great updates below. To preview what's coming in next month’s release, check out our Upcoming Releases page , which includes our 14.5 release kickoff video. Join us for an upcoming event This month's Most Valuable Person ( MVP ) is Ethan Reesor @firelizzard 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 request...