|Features & Demos||Our Youtube playlist|
|Content Last Reviewed||
|Content Last Updated||
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 (email@example.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.
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 try to differentiate how broadly beyond this core function they stretch. Starting farther “to the left”, some vendors include their own vulnerability scanners (typically DAST or, more recently, container scanning) to capture new weaknesses before they are introduced into production. Others extend farther “to the right” by providing integration and feedback loops with infrastructure tools such as IPSes, WAFs, and patch management. Ultimately, all of these additional capabilities will fall well short of their potential if not built around a rock-solid system for not just 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.
We want to extend beyond the capabilities of current vulnerability management systems.
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, Web Application Firewall, and Container Behavior Analytics 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 faciliate 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 Instance, Group and Project level 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. They are also the central place to manage the triage and remediation process as security dashboards reflect vulnerabilities present in the
default branches of projects. Security Dashboards help keep your organization's application security health at a proper level.
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.
Security approvals are an optional feature for merge requests. You create a security approval group much like you would a regular merge request approval group. Then, when merging to the
default branch, if a vulnerability with severity of
Unknown is present, the merge is blocked unless someone in the security approval group approves. This extra layer of oversight can serve as an enforcement mechanism as part of a strong security compliance program.
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.
Now that Vulnerability Management is Minimal, we are focusing on what it will take to move to Viable. We will start by improving the vulnerability triage and management experience. This will include enhancing the MR security report and Security Dashboards.
The other area of focus will be on 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 assest 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.
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 Defend Categories.
You can read more about reporting a vulnerability, our disclosure policy, and request a CVE ID at our Responsible Disclosure page.