### 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. ### Intended users * [Sasha (Software Developer)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#sasha-software-developer) - Sasha will want to report any potential vulnerabilities discovered during development. * [Sidney (Systems Administrator)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#sidney-systems-administrator) - Sidney will want to report any potential vulnerabilities discovered in the infrastructure to which GitLab is deploying applications. * [Sam (Security Analyst)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#sam-security-analyst) - Sam will want to report potential vulnerabilities based on alerts that indicate a potential weakness being exploited. * [Alex (Security Operations Engineer)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#alex-security-operations-engineer) - Alex will want to report a new vulnerability based on any weaknesses exploited in detected attacks. * [Simone (Software Engineer in Test)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#simone-software-engineer-in-test) - Simone will want to report any potential vulnerabilities discovered during testing. ### 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 Instance security dashboards 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 results. 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). ### Permissions and Security <!-- What permissions are required to perform the described actions? Are they consistent with the existing permissions as documented for users, groups, and projects as appropriate? Is the proposed behavior consistent between the UI, API, and other access methods (e.g. email replies)?--> ### 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. ### 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 --> ### What does success look like, and how can we measure that? Our internal AppSec team is able to start managing vulnerabilities manually created inside GitLab that were previously handling outside our application. ### What is the type of buyer? ~"GitLab Ultimate" ### Is this a cross-stage feature? <!-- Communicate if this change will affect multiple Stage Groups or product areas. We recommend always start with the assumption that a feature request will have an impact into another Group. Loop in the most relevant PM and Product Designer from that Group to provide strategic support to help align the Group's broader plan and vision, as well as to avoid UX and technical debt. https://about.gitlab.com/handbook/product/#cross-stage-features --> ### Links / references