### Release notes Today, GitLab's Vulnerability Management ingests and aggregates security findings from our many Secure scanners. We can also seamlessly incorporate results from integrated 3rd-party scanners. While this provides valuable security information in a unified experience, it limits Vulnerability Management to only those vulnerabilities picked up by currently supported tools. We are introducing the ability to manually create vulnerability records to greatly expand the use cases Vulnerability Management can handle. Leveraging our recently-released ability to [directly create vulnerability records via API](https://docs.gitlab.com/ee/api/graphql/reference/#mutationvulnerabilitycreate), making a new vulnerability record is as simple as entering a few required pieces of information. Of course you can also provide any details supported by vulnerability records including CVSS score and suggested solution. Manually created records appear in the Group, Project, and Security Center Vulnerability Reports. Move them through your triage and remediation workflows like you would any scanner-detected vulnerability.  ### Problem to solve Today, all vulnerability objects are created as a result of detections by our Secure scanners or that of an integrated 3rd-party scanner. However, this limits Vulnerability Management to only those vulnerabilities picked up by currently supported tools. To truly make our Vulnerability Management solution suitable for general-purpose use across an organization's entire SDLC (and possibly beyond), we need to provide users with the ability to manually create vulnerability objects. ### User experience goal Manually creating a vulnerability object should be simple, not unlike creating a new issue. Created vulnerability objects will appear in the appropriate Project, Group, and Security Center Vulnerability Reports just like vulnerabilities from Secure scanners do. It should be easy to distinguish between a manually created vulnerability object and one created automatically from a scanner result. It is also important that the user inputs a minimum amount of information about the vulnerability to help it be properly understood and classified by anyone else looking at it. ### Proposal <!-- How are we going to solve the problem? Try to include the user journey! https://about.gitlab.com/handbook/journeys/#user-journey --> ### Further details We need to include public APIs sufficient to allow our users to create vulnerabilities programatically. For instance, a company may have an existing internal form where users can input details of any potential security issues. The customer could then take the output of this form and use it to create new vulnerabilities in GitLab for further evaluation and triage. An API is likely also the preferred method to pull in vulnerability reports from bug bounty programs like Hacker One. We also need to ensure that manually-created vulnerabilities are accessible through the same APIs that the existing vulnerability objects are today. It may make sense to provide a clear way to distinguish the source of manually created vulnerabilities from those caught by scanners. For instance, the source might simply be "API". Alternatively, this could be a user-provided string value as part of the manual create API(s) above such that an organization could distinguish vulnerabilities created from different sources (e.g. an internal form versus a Slack app versus a report/feed from their bug bounty program). ### Requirements In addition to implementation of this new functionality, ensure that https://gitlab.com/gitlab-org/gitlab/-/issues/231026 is addressed at the same time. This will provide consistency and clarity in the Vulnerability Report UI as vulnerability objects can now come from more than just scanners. ##### Availability All functionality needs to be available and work the same for gitlab.com and self-managed customers. Additionally, this new feature is on by default meaning no configuration or user action is needed to start using it, once released. ##### Metrics We need to capture: * Unique visits (sessions) to the new manual creation page * Unique users (sessions) creating a manual vulnerability record * Total number of manually created vulnerabilities, ideally broken out by UI versus API ### Permissions and Security Only users that can access and update the details for vulnerabilities on a Project can create new vulnerability records on the project. ### Documentation This will be net new functionality so we need to clearly document the new feature including: * The different methods for accessing and creating (in GitLab and via API) * General workflow, specifically what happens to a newly created vulnerability * Suggestions on best practices such as create vulnerabilities in the proper project, provide as much information during creation as possible, etc. Additionally, it is necessary to update text and screenshots in the [Vulnerability Report documentation](https://docs.gitlab.com/ee/user/application_security/vulnerability_report/) and any other places where the previously-named `Scanner` column and filter are visible or referenced. The new name is `Method`. ### Availability & Testing <!-- This section needs to be retained and filled in during the workflow planning breakdown phase of this feature proposal, if not earlier. What risks does this change pose to our availability? How might it affect the quality of the product? What additional test coverage or changes to tests will be needed? Will it require cross-browser testing? Please list the test areas (unit, integration and end-to-end) that needs to be added or updated to ensure that this feature will work as intended. Please use the list below as guidance. * Unit test changes * Integration test changes * End-to-end test change See the test engineering planning process and reach out to your counterpart Software Engineer in Test for assistance: https://about.gitlab.com/handbook/engineering/quality/test-engineering/#test-planning→> <!-- triage-serverless v3 PLEASE DO NOT REMOVE THIS SECTION --> *This 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.* <!-- triage-serverless v3 PLEASE DO NOT REMOVE THIS SECTION -->