The following page may contain information related to upcoming products, features and functionality. It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes. Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features or functionality remain at the sole discretion of GitLab Inc.
| Stage | Secure |
| Maturity | Viable |
| Features & Demos | Our Youtube playlist |
| Content Last Reviewed | 2021-06-04 |
| Content Last Updated | 2021-06-04 |
Thanks for visiting this category strategy page on Vulnerability Management in GitLab. This category belongs to the Threat Insights group of the Secure stage and is maintained by Matt Wilson (mwilson@gitlab.com).
At GitLab, we believe everyone can contribute. One of the simplest ways is by contributing your feedback! If you're a GitLab user or an interested security professional, we especially would love to hear from you. Check out all the ways you can engage with us and chose which one is right for you.
Note: At GitLab, we record most of our video calls and will post them to our Youtube channel unless there is sensitive information. Our Office Hours calls will generally be recorded and posted publicly.
Vulnerability management is the process of identifying, prioritizing, and tracking vulnerabilities in assets and applications. At its very simplest, vulnerability management aims to help security professionals efficiently and effectively determine what weaknesses to address in what order. In this mature, relatively crowded space, programs and solutions often differentiate by how much they facilitate these various aspects and beyond by way of additional tools or capabilities. Depending on the extras, you may encounter solutions classified under different terms to distinguish their specific focus areas. Vulnerability assessment vendors scan running applications—often with their own vulnerability scanners (typically DAST or, more recently, container scanning)&mdsash;to capture new weaknesses. Others extend farther “to the right” by providing integration and feedback loops with infrastructure tools such as IPSes, WAFs, and patch management. More recently, Application Security Orchestration and Correlation (ASOC) vendors are focusing more holistically on the application development process by aggregating numerous code and infrastructure scanners, often combined with SCM and even CI/CD integrations. Ultimately, all of these additional capabilities will fall well short of their potential if not built around a rock-solid system for not just identifying and prioritizing the ever-growing pile of vulnerability information the modern security professional must face but one that reduces the friction and breaks through the silos that prevent quick, efficient remediation.
GitLab was recently named as a Challenger in the 2021 Magic Quadrant for Application Security Testing.
We want to extend beyond the capabilities of current vulnerability management systems. Our vision is to provide the most complete solution for managing all aspects of vulnerability-related risks across the entire application lifecycle.
Traditionally, vulnerability management has focused on scans of live web apps and assets along with management of those vulnerabilities in a single tool. At GitLab, we have a broader vision: vulnerabilities should not be collected and managed in isolation but rather should be integrated with the rest of your DevOps lifecycle. To that end, we will continue shifting security left and provide visibility into potential weaknesses during the development phase. Rather than scan only the final running application, we will leverage our powerful Secure stage tools to proactively identify weaknesses in the code before it ever runs.
We will also continue to shift right as we integrate "downstream" with our Container Network Security and Container Host Security solutions. Not only do we plan to consume information on potential vulnerabilities from these tools, we will help complete the loop by tracking remediations and mitigations as they are pushed back out into live environments.
We want to show with vulnerability management that security really is a team effort. We will enable identifying meaningful sets of vulnerabilities, in both your assets and application code, that can be mitigated, managed, and acted upon by your whole team—not just the security organization. We will also support teams with compliance and auditing efforts by effectively being able to show the lifecycle of identifying and mitigating identified vulnerabilities.
We will increase visibility and decrease friction in the DevSecOps workflow by providing unified interfaces and integrations with the systems teams are already using for managing results from the ~"devops::secure" stage, so that there is always a single source of truth and single place for management of security results. And we will continue to facilitate integrations with 3rd-party tools through robust, open APIs and our technology partners.
Vulnerabilities are critical to track throughout the software development lifecycle from discovery through remediation. The way a vulnerability is handled will be highly dependent on its severity, remediation strategy, and the unique internal processes of the teams involved. This need for visibility, traceability, and flexibility requires that we treat vulnerabilities as the unique entities that they are. That's why in GitLab, vulnerabilities are first-class citizens (objects) like an Issue or an MR.
A dashboard should provide a centralized overview of the most relevant information to support informed decision making and evaluating performance toward specific goals. We provide Security Dashboards at the Project and Group level as well as a personal Security Center to support these needs at various levels of organizations. Primarily geared toward security teams and engineering management, they are a key tool for assessing the current security status of your organization's applications as well as gauging vulnerability management performance over time. Vulnerability reports are the central place to manage the triage and remediation process as they reflect vulnerabilities present in the default branches of projects. Vulnerability reports help keep your organization's application security health at a proper level.
Learn more about Security Dashboards and Vulnerability Reports.
Shifting security left is about more than just scanning your application code pre-deployment. It's about catching and fixing potential vulnerabilities before they can make it into the codebase. Merge request security reports present the results of security scans as a diff of the current branch against the target (default) branch. This allows a developer to see the isolated impact of their changes by highlighting any new vulnerabilities introduced. It is now easy to take corrective action against these new security issues as part of the normal development cycle. By addressing them in the MR, it maintains the security level of the default branch and keeps new vulnerabilities from reaching production environments. Merge request security reports can be used in conjunction with Security Gates for a more controlled secure development process.
Pipeline security reports provide a total picture of all security issues present in a branch. Whereas the merge request security report shows only vulnerabilities newly introduced by a given branch and Security Dashboards show only vulnerabilities already present in the default branch, the pipeline security report shows the combination of both. This provides a quick way to see a total snapshot of the "risk load" that will exist in the default branch were the current branch to be merged.
Understanding that an effective, well-defined, repeatable system for assessing the risk and relative priority of a given vulnerability is crucial to success in the Vulnerability Management space. This understanding is what will drive our thinking as we mature the category. To help frame our thinking, three key themes will serve as lenses through which to view how we can improve both the breadth and depth of functionality. Each step up in maturity will include initiatives that improve on all three themes, which are:
While the security industry has no shortage of standards and best practices, almost every organization is unique in which practices they adopt—and how they chose to implement them. This need for flexibility means there is no one size fits all solution when it comes to security (or even one aspect of security). At the same time, unlimited flexibility can be undesirable as it can lead to long setup times and over-complicated customizations. Our philosophy is to provide a best practices-informed set of defaults with settings-driven configuration where we see most need. This will allow rapid rollout and adoption of vulnerability management. Over time, you can adapt the features and workflows to suite your organization's needs down to the team level. Part of this flexibility will also include top-down configurations. By applying settings at the Instance level, you can easily establish new defaults and internal best practices org-wide. And of course where you chose to allow it, these settings can be overridden at the Group or Project level.
Flexibility also means what information we present to the users, when we present it, and in what format. There are multiple roles that will interact with and benefit from various aspects of vulnerability management outside just engineers and security professionals. Serving these roles will encompass everything from dashboard visualizations to reports geared towards non-GitLab users such as CISOs, auditors, and compliance officers. Having the right information in the right context at the right time not only allows for better decision making, it serves as an enabler of the next theme.
The majority of modern security departments are overworked and understaffed. The sheer month-over-month increase in the number of threats, rate of change in environments, accelerating adoption of new technologies, and novel potential attack vectors makes staying on top of things manually effectively impossible. Security software can help—but only if it cuts down more noise than the new signal it detects. This is why making our vulnerability management process as efficient as possible is essential for successful adoption. We will start by making the tedious and time consuming easier through UX enhancements. Longer-term, we will look to automate more and lean on analytics techniques (including ML) to help users make quicker, smarter decisions.
The final theme is perhaps most important of all from a business standpoint. Situational awareness means we will provide the best available information so the user can make a risk-informed decision. This will start by simply adding more depth to the information we show from the existing scanners to help better quantify risk more granularly than a few basic severity levels. Over time, users will have the ability to set custom policies based on configurable definitions of risk tolerance. We will help our customers maintain compliance with industry standards and internal policies by making it easy to map our Vulnerability Management program to risk management and compliance frameworks. We will also start tying in additional sources of information such as external vulnerability feeds, reports from responsible disclosure programs, and alert data from our own Container Security applications. Ultimately, we want our customers to have the best possible understanding of their risk posture as it relates to their entire SDLC.
We have a full roadmap planned for the upcoming year. The following is provided as a guide to understand our current thinking and general direction. As with all roadmaps, this is subject to change at any time.
For a more detailed list of features we are currently planning, refer to these high-level Epics:
We're also hard at work designing features the help move us toward our vision of a best-in-class vulnerability management experience that's an integral part of GitLab's single application for DevSecOps. Here's what we're up to:
1. While Vulnerability Management is now Viable as a category, there are still some open items from the original maturity plan. These will eventually be closed out or migrated forward to the Viable to Complete epic.
The majority of work in Vulnerability Management so far has focused on the core triage and remediation experience. This primarily benefits AppSec teams as it is crucial to their ability to adequately track and manage application vulnerabilities. Now that Vulnerability Management is Viable, we are focusing on what it will take to move to Complete. We will start by improving the MR security experience. For organizations using Jira, you will soon be able to create Jira issues directly from vulnerability objects. We will also complete some crucial improvements for managing vulnerabilities such as bulk status updates and adding the ability to manually enter vulnerabilities. And to better support future efforts to incorporate more tools into vulnerability management, we are hard at work on a new generic security schema that will make it quicker and easier to integrate 3rd-party scanners as well as write custom scanning and detection utilities.
Further out, there are larger initiatives such as executing our design vision for the future of vulnerability management. We will also start laying the groundwork to move from the current severity-based vulnerability classification system to a risk-based classification. Organizations want to understand more context around the potential impact of a given vulnerability. By understanding not just the severity but also the business criticality of the impacted asset along with the likelihood of compromise (how exposed is the asset), the responsible teams can more effectively assess threats and focus mitigation and remediation efforts on the highest risk areas first. We want to enable defensible risk management processes and provide enhanced security visibility and control.
There are dozens of vendors providing vulnerability management as a standalone offering or as part of a larger solution. Some chose to rely heavily on integrations to broader their capabilities while others chose to build and bundle additional functionality. As DevSecOps continues to mature as a concept, expect to see more expansion into traditional DevOps capabilities alongside support for multiple security scan types. To understand the competitive landscape, it is helpful to group vendors based on the capabilities that they offer.
These vendors have broad offerings and are considered leaders in the space by the major analyst firms. Most are more focused on post-deployment application and/or infrastructure scanning (DAST, container). They include their own scanning tools as part of or as an additional option with their vulnerability management tool:
One of the most challenging aspects of vulnerability management is triaging the large volume of vulnerability findings many security professionals must handle. Some vendors have chosen to focus specifically on this vulnerability prioritization aspect. While they typically do not provide scanners, most offer multiple pre-built integrations with various commercial and open source products as well as vulnerability data sources to provide deeper insights than most of the broader vulnerability assessment/management solutions.
Some notable vendors focused on prioritization include:
Gartner distinguishes these vendors by their heavy use of automation in testing application security. They pull data from multiple sources including code scanners (SAST, DAST, SCA) and vulnerability assessments. Some vendors also have begun to ingest infrastructure vulnerability findings to provide an end-to-end view of application security flaws. These tools help prioritize remediation efforts by centralizing the correlation and analysis of findings from a broad source of inputs. You will often find bundled open source security scanners alongside extensive integration capabilities with other commercial security tools. Some of these offerings can also be tightly integrated into CI/CD workflows, making ongoing security assessment part of the DevSecOps flow.
Notable ASOC vendors include:
There are also a few competitors that aren't a direct competitor in the vulnerability management space but offer a much broader challenge to GitLab as a whole. These vendors typically include some security tools that overlap with our own Secure scanners. They also provide closer integrations with or their own CI/CD and SCM solutions. It is conceivable that any of these vendors could add or expand their vulnerability management capabilities, making their value proposition closer to GitLab's.
Vulnerability management is covered slightly differently, depending on the analyst.
GitLab believes in responsibly disclosing software vulnerabilities. As such, GitLab is a CVE Numbering Authority (CNA) and can provide CVE IDs to researchers and information technology vendors. We will be integrating CVE ID request solution which will be available within our Secure and Protect Categories.
You can read more about reporting a vulnerability, our disclosure policy, and request a CVE ID at our Responsible Disclosure page.
