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 | Govern |
| Maturity | Viable |
| Features & Demos | Our Youtube playlist |
| Content Last Reviewed | 2024-02-05 |
| Content Last Updated | 2024-02-05 |
Thanks for visiting this category strategy page on Vulnerability Management in GitLab. This category belongs to the Threat Insights group of the Govern stage and is maintained by Alana Bellucci ([email protected]).
This direction page is a work in progress, and everyone can contribute:
Dependency Management aims to help developers and security professionals understand exactly what 3rd-party software organizations are using to create their own applications. Vulernabilities are ever present in 3rd-party software, surfacing a software bill of materials (SBOM) will aid in exposing what compnents need to be updated. Further the current regulatory landscape with references to SBOM requirements in numerous draft legislation in both the U.S. and non-U.S., executive orders and directives, customer requests, and numerous community frameworks and formatting specifications. The ability to generate and consume complete and accurate SBOMs is essential for securing our software and managing our software supply chain risk.
SBOMs have been referenced as a requirement for U.S. Federal Agencies to do business with software providers in and Executive Order, the National Cybersecurity Strategy, NIST SSDF standard, CISA, and is already appearing in draft legislation and Requests for Information (RFI). Non-U.S. public sector and commercial regulatory frameworks are following suit, and the regulatory landscape is expected to very dynamic over the coming years.
Our vision captures what we want to deliver to customers in the next 10 years.
Over the next year (major milestone 16.0-16.11), we aim to enable the abilitiy for leadership to have visibility to dependencies in any project, sub-group, group or instance level view. We also want to make sure teams can quickly triage their dependencies with filters, searching and grouping within the dependency list.
We are working on multiple iterations of the Group/Sub-Group Level Dependency List. Enhancements will include:
Insights Visibility on dependencies, versioned component, vulnerability state, and adherence to compliance. The importance of insights is the ability to prioritize and triage dependencies from a project and organizational level. This allows organizations to assess risk and meet compliance to internal/external requirements.
Remediation A combination of manual and automated methods can be used to update and resolve dependencies. By manual is informing the user of its version, vulnerable state, and upgradability. By automated are solutions involving a MR to update the package file with version and description of changes such as changelog, CVE, and merge confidence.
Policies A policy can include remediation rules, authorized dependencies, CVE validation, vulnerable tolerance, compliance and more. This policy can then be flagged at the MR, continuously, or on-demand.
Alerting A combination of notifications to chat platforms (Slack, Teams, etc) or email alerts. Notifications include a report of a new vulnerable dependency or weekly report of dependency insights. These can be scheduled or policy-driven.
