<!--Implementation issues are used break-up a large piece of work into small, discrete tasks that can move independently through the build workflow steps. They're typically used to populate a Feature Epic. Once created, an implementation issue is usually refined in order to populate and review the implementation plan and weight. Example workflow: https://about.gitlab.com/handbook/engineering/development/threat-management/planning/diagram.html#plan--> ## Product - User Stories **Who is this for?** * appSec can filter out ‘unreachable’ CVEs, in cases where the vulnerable method or class is not present in the code itself. This allows appSec to push a higher rate of true positives to developers, creating efficiency.  * Developers can now spend their time on real security issues rather than triaging potential false positives and pushing back on appSec. **User Stories** * As application security, I want to be able to understand if the package itself is reachable in the given project when its compiled, and I want to understand if the vulnerable method is. Being able to understand that context when prioritizing CVEs or vulnerability is important, so only truly risky issues are pushed to developers, so time is spent truly reducing risk and improving security posture with minimal waste. * For example: All CVEs under unreachable libraries (is not actually imported) are not important to prioritize. AppSec can filter those out. * A CVE that is reachable, IE, the method itself is called in the code, then appSec would want to specifically identify that vulnerable and create an issue around it. **What are the features/iterations nested under this epic?** * Show Users Reachability (of a Library/Component) * As application security, I want to be able to understand if the method that causes a given CVE is actually explicitly used in the application code. Being able to understand that context when prioritizing issues, so only truly risky and exploitable issues are pushed to developers. Time is spent truly reducing risk and improving security posture with minimal waste. * Show if the vulnerable library is reachable (actually imported in the app at runtime) in the vulnerability report, depenency and vuln details in UI and API. * Since this is at the CVE level, the vulnerability report UX may be more straightforward (since there are CVEs as entities in that view. * The severity of the CVE should be downgraded if the CVE is not detected to be reachable * Show if the vulnerable function is reachable for a given CVE (actually called in the app) in the dependency list: * Since this view is at the library level. This may require more creative UX on the modal that renders when you click on the vulnerabilities view. * This data should be shown on the group subgroup and project level. * The UX should clearly indicate this is at the package level and not the function level which is a seperate but important notion of reachability. ## Why are we doing this work Full scope, to be broken down into smaller issues if necessary. 1. Vulnerability report table - show an indicator that designated `Reachable` 2. Vulnerability report, vulnerability details page - add a badge or indicator that states `Reachable: True or `~~`False`~~` Not available` (see screenshot below for proposed placement on page 3. **Out of scope for this issue:** Vulnerability report filter - `Reachable || True or `~~`False`~~` Not available` (will need additional gitlab~2492649 ) Note: for cases where something is not reachable we do not need to show this as it will be information overload. The user can assume that anything not labeled `Reachable` is unreachable. Though I would welcome feedback on this thought from Design. ## :art: Design Design issue: https://gitlab.com/gitlab-org/gitlab/-/issues/480356+ | Vulnerability Report | Vulnerability Details | |----------------------|-----------------------| |  |  | ## :pencil: Requirements - Phase 1: Project and Group level (https://gitlab.com/gitlab-org/gitlab/-/issues/480356#note_2304793065). - Optional: Security center (Instance) can be done in Phase 2 if needed Displayed text: | API `reachability` | Displayed Text | |--------------------|----------------| | `not_found: 2` | Reachable: Not found | | `in_use: 1` | Reachable: Yes | | `unknown: 0` or "not true" | Reachable: Not available | ## :construction_site: Implementation plan DRI: - ~backend: ~"group::composition analysis" @nilieskou - ~frontend: @charlieeekroon | Type | Team | Issue | |------|------|-------| | ~"type::feature" | ~backend | https://gitlab.com/gitlab-org/gitlab/-/issues/513990+s | | ~"type::feature" | ~backend | https://gitlab.com/gitlab-org/gitlab/-/issues/513991+s | | ~"type::feature" | ~frontend | https://gitlab.com/gitlab-org/gitlab/-/issues/513993+s | | ~"type::feature" | ~frontend | https://gitlab.com/gitlab-org/gitlab/-/issues/513995+s | | ~"type::feature" | ~frontend | https://gitlab.com/gitlab-org/gitlab/-/issues/513989+s | | ~"type::feature" | ~frontend ~"Technical Writing" | https://gitlab.com/gitlab-org/gitlab/-/issues/513992+s | | ~"type::maintenance" | ~frontend | https://gitlab.com/gitlab-org/gitlab/-/issues/513994+s |