### Problem to solve Users struggle to find bugs and vulnerabilities that traditional QA processes and tests miss. It is difficult and time consuming to do "dumb" fuzzing with random inputs that frequently produce no actionable results. ### Further details ### Intended users Both [Sam (Security Analyst)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#sam-security-analyst) and [Sasha (Software Developer)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#sasha-software-developer) can be targeted users for this MVC. ### Proposal Introduce coverage-guided fuzzing to GitLab so that users can add it to their pipelines. Show fuzz test results to users in a simple manner that fits with the existing GitLab pipeline and security paradigms. Integrate usage ping in the various fuzz testing touchpoints so we can understand how users are using the product. Initial focus is on Go language - Add additional ones in an iterative fashion in future issues. **Minimal Requirements / Issues** 1. [Provide a CI job template (e.g. `Fuzzing.gitlab-ci.yml`) that users can include in their pipelines.](https://gitlab.com/groups/gitlab-org/-/epics/3301) 1. [Provide a downloadable report of the fuzz test results](https://gitlab.com/gitlab-org/gitlab/issues/217151) 1. [Report usage statistics](https://gitlab.com/gitlab-org/gitlab/issues/217152) 1. [Comprehensive user documentation](https://gitlab.com/gitlab-org/gitlab/issues/217153) **Post MVC Requirements / Issues** 1. [Fuzz results in Merge Request widget](https://gitlab.com/gitlab-org/gitlab/issues/210343) 1. [Fuzz results in project Security Dashboard](https://gitlab.com/gitlab-org/gitlab/issues/212214) 1. [Fuzz testing in AutoDevOps](https://gitlab.com/gitlab-org/gitlab/issues/212198) 1. [Fuzz testing configuration in Security & Compliance Configuration screen](https://gitlab.com/gitlab-org/gitlab/-/issues/213837) ### Permissions and Security Users must be ~"GitLab Ultimate" users to use fuzzing. ### Documentation Documentation should cover at a minimum: 1. Description of what fuzzing is. 1. Description of the problem fuzzing solves. 1. Technical instructions for adding our fuzzer to a project. 1. Screenshots are required for this. 1. Technical instructions for understanding the results from fuzzing. 1. Screenshots are required for this. 1. An example of walking through a project and using the fuzzer. ### Testing A test plan is required which includes automated testing that will be done on an ongoing basis to prevent regressions. Approval from the Quality team required for the test plan. Testing should cover at a minimum: 1. The "happy flow" where a user adds a project and begins to fuzz it 1. Offline mode where no internet connection is present 1. _What else? Add to this list organically_ Must meet the [definition of done](https://gitlab.com/gitlab-org/gitlab-foss/-/blob/master/doc/development/contributing/merge_request_workflow.md#definition-of-done) ### What does success look like, and how can we measure that? 1. Number of GitLab Ultimate accounts with pipelines with fuzzing enabled within 90 days of completion of this epic. (Target => 50) - This will ensure that we are seeing adoption of the new fuzzing capabilities. We will then have a set of users we can use for additional feedback. If we _don't_ see adoption, that is a flag we need to investigate more in terms of why we users aren't using it. ### Links / references [Swagger and Open API Specification](https://swagger.io/resources/open-api/)\ [Peach Tech API Security](https://www.peach.tech/products/peach-api-security/)\ [Peach Community Edition](https://www.peach.tech/resources/peachcommunity/)\ [Sulley Framework](https://github.com/OpenRCE/sulley)