 Developers want to find and fix vulnerabilities while they work on the code. While GitLab focused first on enabling developers within the CI pipeline or MR report, we recognized that security pros also need tools to see and to manage the risk of unresolved software vulnerabilities. Early visibility is becoming even more important, along with obtaining this insight simply and without added heroics. In the past year, we've added more focus and investment to help the security pros. Lindsay Kerr is a front-end engineering manager with GitLab, whose team focuses on the security user. She's excited to show you how GitLab has evolved our vulnerability management capabilities, and she'd love to hear your feedback as well. Hi, I'm Lindsay Kerr. I'm here to share with you the story of how we've evolved the vulnerability management features of GitLab over the past year. It's a thrilling tale of iteration, collaboration, and progress. I'm incredibly proud of the accomplishments made by our team so far, and I'm really excited to share the details with you today. I'll start by telling you a bit about myself. As I said, my name is Lindsay. I have been an engineering professional since 2002. My background as a developer is pretty diverse. I've written Kobo, Java, SQL, Perl, ActionScript, JavaScript, and more. Fueled by my enthusiasm about Scrum and Agile development practices, as well as my natural tendency towards bossiness, a term that I'm trying to reclaim as a compliment, I made the leap into engineering management in 2012. I joined GitLab in November of 2019. I managed the front-end engineering team responsible for developing the vulnerability management category of our product. This team is called the Threat Insights Group, and our features fall into the secure stage of the GitLab product. I was born and raised in Oregon. I live in Eugene now, but I've had the opportunity to live in really cool cities like Chicago, San Francisco, and Portland before this. At my free time, I enjoy gardening, kayaking, and reading to my daughter. I'm thrilled to be here sharing my experiences with you all at GitLab Commit. Please share your questions and feedback in the chat. So, what exactly do I mean when I talk about vulnerability management? We all know what security vulnerabilities are, or at least I hope so. When I talk about managing vulnerabilities, things may become a little less clear. According to GitLab, vulnerability management is the recurring process of identifying, classifying, prioritizing, mitigating, and remediating vulnerabilities. That's a mouthful. Let's dig into that a bit. It's one thing to know that you have a vulnerability in your application code, but that's only the first step in the lifespan of a vulnerability. It's nice to think that all vulnerabilities can be remediated upon first detection, but unfortunately, that's not always practical or possible. And even more than other bugs found in your development process, ensuring the security vulnerabilities are remediated is increasingly important. My team builds the interfaces within the GitLab product that help engineers and security analysts manage the lifespan of application vulnerabilities. Whether it's early detection of a vulnerability before it's merged into the code, triaging an existing vulnerability found when scanning a legacy application or somewhere in between, we work to create solutions that provide visibility at all stages of the vulnerability's lifespan. To be clear, other groups within GitLab develop our security scanners, such as static, dynamic, and composition analysis, fuzz testing, dependency scanning, and secret detection. Our group is responsible for making sure that the results of these scanners, as well as any third-party scanners integrated into your pipeline, are delivered in a way that empowers customers to collaborate in a transparent and secure fashion, just like everything we do at GitLab. Let me illustrate this a little more with a picture, because everything is more clear with a picture. Vulnerability management focuses primarily on two personas, the developer and the security team. You can see clearly in this diagram where those touch points are. On the left, developers discover that there are vulnerabilities in their code through our MR security widget, and can find more details in the pipeline security report. They work iteratively to remove vulnerabilities as they work on their code. On the right, security teams classify, prioritize, and track vulnerabilities across projects and groups using our security dashboards and vulnerability reports. They work on vulnerabilities that remain unresolved after the developer merges their code. I'll show you all of these areas in our product in detail in a little bit. Since our predecessors in Secure had already built features to enable developers, our MR security widget and pipeline security report, we turned our attention to building solutions to assist security teams. We've spent the majority of the last year and a half making improvements to the project, group, and instance-level security dashboards and vulnerability reports. Let's take a closer look at that journey. When I joined GitLab, vulnerabilities had a very limited lifespan. Besides some aggregate data, they were not starting a database. Details about a vulnerability were read directly from JSON results produced by the various security scanners in our CI CD pipeline and were presented in a modal, meaning there was no way to share a link with someone else. There was also no dedicated team focused on creating the delivery system for the security scanner results. This responsibility was shared across the various scanner groups in the secure stage. The introduction of the Threat Insights group consolidated the ownership of vulnerability management to 1 p.m., one designer, and one dedicated engineering team. We were almost all of us were very new to GitLab, and we inherited a wealth of ambitious plans from our peers in secure. Needless to say, 2020 was filled with challenges that no one could predict. We were a brand new engineering team. Most of our developers joined GitLab before April of 2020. There was high customer demand for enhanced security features as the industry continued to shift security left in their deployment processes. And of course, we embarked on this journey at the onset of a global pandemic. What better way to bond as a team and distract ourselves from world news than to take on a giant architectural overhaul of our area of the product right out of the gate? Well, this may not sound very iterative. One of GitLab's core values. It was the building block needed to allow us to iteratively build features on top of it for the next year to come. In GitLab 13.0, we introduced standalone vulnerabilities to the world. We now store vulnerabilities in our production database. Once a security scanner result referred to as a finding is merged into the default branch, it becomes, it graduates to become a standalone vulnerability and is inserted into our database. Getting to this point required extensive knowledge of GitLab's security scanners and how they function in our CI CD pipelines. Depending on the project, some of our security scanners can produce a lot of results. Given that we are going to be creating a large amount of data in GitLab's production database, we really had to consider scaling and performance. Building reports, capturing this much data creates front-end challenges as well. I personally had no idea that filtering these reports was going to be such a struggle. For a team that was comprised of all new engineers at GitLab, none of this was an easy feat. Fortunately for us, we hired an amazing team of software engineers who were definitely up to the challenge. By creating what we originally called first-class vulnerabilities since they were becoming first-class objects in GitLab, but later renamed to standalone vulnerabilities, we were able to build an ecosystem where vulnerabilities could be managed in a very similar way to how GitLab issues and MRs are managed. Let's talk about some of the features that the introduction of standalone vulnerabilities enabled us to build. A huge win for our users is something that may seem quite small unless you don't have one. A URL. A dedicated page tracking a detected vulnerability can now be bookmarked, linked to, and shared. This immediately increased visibility and opportunities for collaboration. The concept of a vulnerability status was also introduced along with standalone vulnerabilities. So vulnerabilities now have statuses much like workflow states that allow easier triage and tracking of security scanner results. In order to make referring to vulnerabilities as simple as possible with in GitLab, we adopted the new special reference format shown here. Typing vulnerability, call on vulnerability ID, and brackets into the comments or description of an issue or MR creates a quick link to that vulnerability for easy reference. In addition to what I've already described, here are a few more features that we've added since the introduction of standalone vulnerabilities. Previously, our vulnerability report and security dashboard charts shared one page. This limited us in our future visions for new charts, but it also hit us from a performance perspective. It was a lot to load on one page. We've split these two functions into two separate pages. Our dashboard charts have been improved using Apache's amazing open source JavaScript visualization library, eCharts. We're also designing new charts that we now have the real estate needed to include on this page. These new features were all included in the most recent addition to our report levels, the instance level security center. This is a user centric security center that is built right into the GitLab platform allowing customers to configure what projects across multiple groups are included in their personal security dashboard and vulnerability report. This is essential for security teams who monitor vulnerabilities across an entire organization so they can keep an eye on vulnerabilities across all of the projects and groups they're concerned with. Likewise, more cool features were also added to our now standalone vulnerability report page. You can export the entire vulnerability report as a CSV file enabling security teams to slice and dice this data however they want. A new sortable column was added to indicate the date that the vulnerability was first detected. And on our project level vulnerability report we've added a banner at the top of the page that displays information about the last successful pipeline run in that project and a link that'll take you directly to that pipeline. We've also improved our scanner filter so that it'll automatically display the name and results of third-party analyzers configured in your pipeline. We're in the process of updating the pipeline security report to use the shared components from these other vulnerability reports. Once we do that, this will apply most of these same features to that report as well. Well, screenshots are great but demos are even better. So let me walk you through some of this experience to demonstrate the features that I just described. Here's a demo group created for showing off our security features. And here is an example MR to show the first touch point where a developer can learn about vulnerabilities detected by the security scanners in their pipeline run. We refer to this portion of the UI that my team manages as the MR security widget. Here you see the modal presenting details about the vulnerability and options to dismiss or create an issue. A complete report of the vulnerability findings in the pipeline can be found by clicking the View Full Report button. Here, or by navigating to your successful pipeline run and selecting the Security tab, note that the pipeline report shows only the new vulnerabilities detected in the pipeline. This is important for accountability, ensuring that developers are aware of any vulnerabilities they are introducing with their changes. Selecting a record launch is the same modal that we link to from our MR security widget. As I mentioned earlier, our investment over the past year has been largely focused on the security team persona, so I won't spend too much time talking about the MR widget or pipeline report today, which were built to be used by developers. Any vulnerabilities present in the pipeline when the MR is merged will then be present in our other vulnerability reports. Here is the project level vulnerability report for this same project. Some of the features available here that I'd like to point out, as I mentioned before, we've got the link to the most recent pipeline execution at the top of the page, as well as the Export as CSV option. We've also enhanced our filtering and our sorting options of this data. Additionally, if you want to change the status of multiple vulnerabilities at one time, you can select the checkbox next to each record and then using the now exposed bulk status change menu, you can choose the vulnerability status that you would like to set these items to. I'm going to click on one of these vulnerabilities and demonstrate to you the new vulnerability detail page. From the vulnerability detail page, you can view all of the detail delivered to us by the scanners. You can also see the link that goes directly to the pipeline where this vulnerability was detected. You can change the status of this individual vulnerability. You can create a new issue, and I'll walk you through that flow as well. Note that the issue is pre-populated with the details of the vulnerability right away, and this includes a very convenient link to take you right back to the vulnerability itself. Essentially, we'd like to have linked vulnerabilities displayed in a more permanent portion of this issue UI, but this was a great iterative step to provide the same benefit to our customers without a lot of interaction with other groups within GitLab. It's important to call out that you can only create one issue from a vulnerability, but you can link as many related issues as you would like. So now I'm going to take you to our security center. This is an instance-level personalized center where I can configure my own preferences to show which projects I would like to see in the security dashboard and vulnerability report. I've already pre-configured this to show a number of projects that are under the demo group that we were looking at previously. And here's the resulting security dashboard to illustrate the charts that we're currently supporting. On the left, we have our vulnerabilities over time trend chart, and on the right, we have our project security status report. This is like a report card for all of the projects within this view. It breaks down the projects that I've configured based on an A to F grading scale, allowing security teams to focus on projects with the greatest risk. Our product designers have a lot of great ideas for new charts that we can now accommodate for on this dashboard in the future since we've dedicated a full page to it. You can see that our security center vulnerability reports, as well as our group-level vulnerability report, have an additional filter that was not found on the previous project-level report that we were looking at. This project filter allows me to choose the results from whichever project that I would like to drill into. The rest of the functionality on this report is the same as what we saw previously on the project-level report. We've got a lot of exciting new features already in the works for upcoming releases. A few interesting ones to call out are linked to here. These slides will be made available after the presentation. Since GitLab is so transparent, it's super easy for you to stay informed and even share your support for upcoming features by giving us a thumbs up to vote for issues in future milestones or in our backlog. Another easy way to learn about what is slated for upcoming releases is just Google GitLab Upcoming Releases. From there, you can see a list of features that our product manager has prioritized. And don't forget at GitLab, anyone can contribute. We welcome community contributions to advance us on this journey. It's been my pleasure to share the story of our past year. I welcome your feedback and questions in the chat, or you can reach out to me via GitLab or LinkedIn if something comes to mind later. Thank you again for joining us at GitLab Commit. I look forward to hearing your questions.