### Problem to solve REST APIs power web applications and integrations between applications with JSON becoming a more popular notation in use within REST API resources. Developers and security analysts need a way to validate API stability and security without it being a burden. Implementing API fuzzing support within the CI/CD pipeline enables GitLab users to get immediate results with every build and merge request. ### Further details Today [OWASP ZAP](https://github.com/zaproxy/zap-core-help) is implemented for DAST. This tool can support fuzzing of web resources and specifically the input it identifies. ZAP can be verified to meet this initial MVC however other solutions like [Peach Fuzzer Community Edition](https://www.peach.tech/resources/peachcommunity/) and [Sulley framework](https://github.com/OpenRCE/sulley) should be explored as they will allow for long term extensibility. ### 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 Provide fuzz testing for APIs to users as part of their GitLab pipelines that are defined in the [OpenAPI format](https://www.openapis.org/). Allow them to define this directly as part of the pipeline and then provide the results back in a downloadable artifact as part of the pipeline artifacts. - A downloadable PDF report builds off of existing technology we have for fuzz testing, which is why we will start with this, rather than at the MR widget. This could also be a JSON/XML file if that is easier technically. Identify the testing framework (e.g. PyTest, JUnit, etc) being used in the project and fuzz those automatically. - [ ] Decide if we should start with just one or if we can do multiples as part of MVC Fuzzing will be done as part of a pipeline, so the fuzzing job _must_ be able to finish within that specified amount of time without timing out. **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/gitlab-org/gitlab/issues/210342) 1. [Provide a downloadable report of the fuzz test results](https://gitlab.com/gitlab-org/gitlab/issues/212197) 1. [Report usage statistics](https://gitlab.com/gitlab-org/gitlab/issues/210345) 1. [Comprehensive user documentation](https://gitlab.com/gitlab-org/gitlab/issues/210344) **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)