Fuzz testing results in MR widget - API Fuzz Testing
<!-- The first three sections: "Problem to solve", "Intended users" and "Proposal", are strongly recommended, while the rest of the sections can be filled out during the problem validation or breakdown phase. However, keep in mind that providing complete and relevant information early helps our product team validate the problem and start working on a solution. --> ### Problem to solve Fuzz testing provides lots of valuable information to users in terms of ways to crash the app. Currently, it is difficult for them to access this information since it is buried in individual pipeline results, rather than in other screens they regularly interact with, such as the Merge Request widget. ### Intended users * [Sasha (Software Developer)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#sasha-software-developer) * [Simone (Software Engineer in Test)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#simone-software-engineer-in-test) ### Further details ### Design 1 (In scope if https://gitlab.com/gitlab-org/gitlab/-/issues/12896 is NOT done) **When implement it in an old MR widget** | Old MR widget collapsed | Old MR widget expanded | | ------------------ | ----------- | | https://www.figma.com/file/ckuKpzAUe7M0iAF9NdnDQl/Fuzz-testing-MR-page?node-id=4%3A0 |https://www.figma.com/file/ckuKpzAUe7M0iAF9NdnDQl/Fuzz-testing-MR-page?node-id=1%3A2| | We contribute the number if we can tell the findings are new or not | Download artefacts available from this page, rest is the same as other scanners | |![Old-MR-widget-collapsed](/uploads/26b794396caae548f5d5fedec4b6648b/Old-MR-widget-collapsed.png)|![Old-MR-widget-expand](/uploads/f529a97b64c058c4e5bd1a119b211420/Old-MR-widget-expand.png)| ### Design 2 (In scope if https://gitlab.com/gitlab-org/gitlab/-/issues/12896 is done) **When implement it in a one new MR widget** | New MR widget collapsed | New MR widget leads to a new tab | | ------------------ | ----------- | |https://www.figma.com/file/ckuKpzAUe7M0iAF9NdnDQl/Fuzz-testing-MR-page?node-id=3%3A142| https://www.figma.com/file/ckuKpzAUe7M0iAF9NdnDQl/Fuzz-testing-MR-page?node-id=3%3A1236| | We contribute the number if we can tell the findings are new or not| | | ![New-widget-summary](/uploads/27f1f6cc678748c54754d394f742c707/New-widget-summary.png)|![new-widget-list](/uploads/f51c727752426594552f5cfb4577f6e3/new-widget-list.png)| ### Design 3 (Definetely in scope) **No matter old or new MR widget, the modal window details keep the same** | API fuzzing | API fuzzing -expanded-request | tooltip | | ------------------ | ----------- | --------- | |https://www.figma.com/file/ckuKpzAUe7M0iAF9NdnDQl/Fuzz-testing-MR-page?node-id=78%3A934| https://www.figma.com/file/ckuKpzAUe7M0iAF9NdnDQl/Fuzz-testing-MR-page?node-id=78%3A1696 |https://www.figma.com/file/ckuKpzAUe7M0iAF9NdnDQl/Fuzz-testing-MR-page?node-id=42%3A17| |https://www.figma.com/file/ckuKpzAUe7M0iAF9NdnDQl/Fuzz-testing-MR-page?node-id=42%3A352| | https://www.figma.com/file/ckuKpzAUe7M0iAF9NdnDQl/Fuzz-testing-MR-page?node-id=121%3A229 | |show full lines of request, reset will be hidden until user expanded it | | https://www.figma.com/file/ckuKpzAUe7M0iAF9NdnDQl/Fuzz-testing-MR-page?node-id=121%3A68| | ![Old-MR-details-API-1](/uploads/d32f1d52c31881312ed11e58bb3cc815/Old-MR-details-API-1.png) ![Old-MR-detail-API-2](/uploads/b131d6686d86bd921a1babdfeabb0c6f/Old-MR-detail-API-2.png)|![Old-MR-details-API-expanded](/uploads/a8ce73facbcc34fb756106956ceb5bdc/Old-MR-details-API-expanded.png) | ![Old-MR-detail-API-2-tooltips1](/uploads/d1078b8a48412a6436492b5b10687fb8/Old-MR-detail-API-2-tooltips1.png)![Old-MR-detail-API-2-tooltips2](/uploads/c41af193d7728e7597a38c54fcc2fbfd/Old-MR-detail-API-2-tooltips2.png)![Old-MR-details-API-1-tooltip](/uploads/34235e43e8a75682c6cecf4ca46f9beb/Old-MR-details-API-1-tooltip.png)| - :movie_camera: Video walkthrough: https://youtu.be/rKX1MJsHFCo ### 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 <!-- See the Feature Change Documentation Workflow https://docs.gitlab.com/ee/development/documentation/feature-change-workflow.html * Add all known Documentation Requirements in this section. See https://docs.gitlab.com/ee/development/documentation/feature-change-workflow.html#documentation-requirements * If this feature requires changing permissions, update the permissions document. See https://docs.gitlab.com/ee/user/permissions.html --> ### 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? <!-- Define both the success metrics and acceptance criteria. Note that success metrics indicate the desired business outcomes, while acceptance criteria indicate when the solution is working correctly. If there is no way to measure success, link to an issue that will implement a way to measure this. --> Add usage ping to record the number of times users view the fuzz testing results. ### What is the type of buyer? <!-- What is the buyer persona for this feature? See https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/buyer-persona/ In which enterprise tier should this feature go? See https://about.gitlab.com/handbook/product/pricing/#four-tiers --> ### 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&gitlab#39;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 ### Implementation Strategy #### Prior Work Summary: This will follow an implementation approach that mirrors what we did for coverage fuzzing. So there are less unknowns. I will link the merge requests for Coverage Fuzzing frontend and backend merge requests to use for reference. ~frontend https://gitlab.com/gitlab-org/gitlab/-/merge_requests/36011 gitlab#255169 https://gitlab.com/gitlab-org/gitlab/-/merge_requests/43983 https://gitlab.com/gitlab-org/gitlab/-/merge_requests/43531 https://gitlab.com/gitlab-org/gitlab/-/merge_requests/44263 https://gitlab.com/gitlab-org/gitlab/-/merge_requests/43545 https://gitlab.com/gitlab-org/gitlab/-/merge_requests/36676 ~backend gitlab!37173 ### Feature category needed otherwise we will have issues with the api reports route. https://gitlab.com/gitlab-org/gitlab/-/merge_requests/43664 https://gitlab.com/gitlab-com/www-gitlab-com/-/merge_requests/63773 ------ #### Implementation for API Fuzzing ~frontend MR Widget: 1. Create API Fuzzing MR widget feature flag 1. Create API Fuzzing MR widget rollout issue 1. Add new report type to `ee/app/assets/javascripts/vue_merge_request_widget/mr_widget_options.vue` 1. Add help path to `ee/app/assets/javascripts/vue_merge_request_widget/mr_widget_options.vue` 1. Add API Fuzzing section in Mr widget component in `ee/app/assets/javascripts/vue_shared/security_reports/grouped_security_reports_app.vue` 1. Add API fuzzing popover in mixin in `ee/app/assets/javascripts/vue_shared/security_reports/mixins/security_report_mixin.js` 1. In Security Reports store directory `ee/app/assets/javascripts/vue_shared/security_reports/store/actions.js` - Duplicate Coverage Fuzzing state for API fuzzing - Duplicate Coverage Fuzzing actions for API fuzzing - Duplicate Coverage Fuzzing getters for API fuzzing - Duplicate Coverage Fuzzing mutations for API fuzzing - Duplicate Coverage Fuzzing mutation types for API fuzzing - Add API Fuzzing type to mediation in `ee/app/assets/javascripts/vue_shared/security_reports/store/mediator.js` 1. Add unit tests for all sections above Vuln Modal: 1. Add API fuzzing specific modal fields to `ee/app/assets/javascripts/vulnerabilities/components/details.vue` 2. Detail individual new fields to add in UI and from endpoint Artifact Download in MR widget: 1. Create dedicated Vuex module for API fuzzing based on https://gitlab.com/gitlab-org/gitlab/-/merge_requests/36676 - Either recreate Vuex module for API Fuzzing, OR attempt to make the module more generic and support two report types. coverage_fuzzing / api_fuzzing - Whether we do the refactor or implement a new vuex module is dependent on the generic graphQL endpoint being completed in gitlab#251015 which is a blocker for artifact download in the MR widget. This differs from the Vuln endpoint which shows the Vuln Details + artifact downloads which is part of https://gitlab.com/gitlab-org/gitlab/-/issues/270929 ~frontend | Tasks # | Description | ~frontend issue | ~frontend weight | | ----------- | -------------------------------------------------------------- | ---------------------------------------------------- | ---------------------- | | 1 | Implement API Fuzzing MR Widget| https://gitlab.com/gitlab-org/gitlab/-/issues/277341 | ~"frontend-weight::5" | | 2 | Update API Fuzzing Modal | https://gitlab.com/gitlab-org/gitlab/-/issues/277342 | ~"frontend-weight::3" | | 3 | ~~Docs and enable feature flag~~ | ~~https://gitlab.com/gitlab-org/gitlab/-/issues/277349~~ | ~"frontend-weight::2" | ~backend | Tasks # | Description | ~frontend issue | ~frontend weight | | ----------- | -------------------------------------------------------------- | ---------------------------------------------------- | ---------------------- | | 1 | Add backend api_fuzzing_reports operation to MR for API Fuzzing | https://gitlab.com/gitlab-org/gitlab/-/issues/273031 | ~"backend-weight::2" | | 2 | Produce security report in production (after frontend work) + docs | https://gitlab.com/gitlab-org/gitlab/-/issues/270207 | ~"backend-weight::2" ## Follow up frontend/backend for API Fuzzing pipeline jobs Artifact Download | Tasks # | Description | ~frontend issue | ~frontend weight | | ----------- | -------------------------------------------------------------- | ---------------------------------------------------- | ---------------------- | | 1 | Artifact Download in MR widget | https://gitlab.com/gitlab-org/gitlab/-/issues/277348 | ~"frontend-weight::5" | | 2 | Add ability to download reports from Secure jobs (Needed for artifact download) | https://gitlab.com/gitlab-org/gitlab/-/issues/251015 | ~"backend-weight::3" | 3 | Artifact Download + Reproduction Assets in Vuln Modal | https://gitlab.com/gitlab-org/gitlab/-/issues/292890 | TBD ---- ## Notes This is the same amount of work frontend wise for Coverage Fuzzing, but more than https://gitlab.com/groups/gitlab-org/-/epics/4485, because this current issue is essentially three large issues https://gitlab.com/groups/gitlab-org/-/epics/4485 https://gitlab.com/gitlab-org/gitlab/-/merge_requests/36676 https://gitlab.com/gitlab-org/gitlab/-/merge_requests/36011
epic