<!--IssueSummary start--> <details> <summary> Everyone can contribute. [Help move this issue forward](https://handbook.gitlab.com/handbook/marketing/developer-relations/engineering/community-contributors-workflows/#contributor-links) while earning points, leveling up and collecting rewards. </summary> - [Collaborate/take over this issue](https://contributors.gitlab.com/manage-issue?action=work&projectId=278964&issueIid=599426) </details> <!--IssueSummary end--> > **Note:** This issue was raised by **GitLab Duo** on behalf of a user, based on a customer report and verification against the current code in `master`. Please sanity-check the file references and proposed wording before scheduling. ### Summary On the vulnerability details page, a dismissible alert near the top of the page shows **"Vulnerability resolved in $branch"** while the vulnerability's workflow status badge still shows **"Needs triage"**. This combination is confusing for users, who interpret "resolved in $branch" as meaning that no further action is required, even though the workflow state indicates that triage and follow-up are still pending. The fix is primarily a **title rewording** in the resolution alert component, so that it aligns with both the existing alert body text, the docs terminology ("No longer detected"), and the internal event naming (`vulnerability_no_longer_detected_on_default_branch`). ### Customer context From a customer ticket (internal only – ZD 715516): - Near the top of the vulnerability details page, inside the `data-testid="vulnerability-header"` wrapper, the resolution alert renders: ```html <h2 class="gl-alert-title">Vulnerability resolved in $branch</h2> ``` with the alert body: > *The vulnerability is no longer detected. Verify the vulnerability has been remediated before changing its status.* - Directly below, the status badge still shows: ```html <span class="gl-badge-content">Needs triage</span> ``` The customer's feedback is that this inconsistency can cause confusion for security and application teams, as the remediation state shown does not align with the current workflow status. The vulnerability status and the banner messaging should be aligned to accurately reflect the true state of the finding. ### Where this lives in code The conflicting wording does **not** come from the page header component itself. It comes from the **resolution alert** rendered inside the header area: - File: `ee/app/assets/javascripts/vulnerabilities/components/resolution_alert.vue` - The title is built by the `resolutionTitle` computed property: ```js resolutionTitle() { return this.defaultBranchName ? sprintf(__(`Vulnerability resolved in %{branch}`), { branch: this.defaultBranchName }) : __('Vulnerability resolved in the default branch'); }, ``` - The body already contains the more accurate phrasing: ```js __( 'The vulnerability is no longer detected. Verify the vulnerability has been remediated before changing its status.', ) ``` - The alert is **dismissible** and the dismissal is remembered per vulnerability via the `dismissed_resolution_alerts` cookie (90-day expiry). The perceived "conflict" therefore only appears until the user dismisses the alert for that vulnerability. The alert is mounted by `ee/app/assets/javascripts/vulnerabilities/components/header.vue`, which also renders the status badge that reflects the workflow state (`vulnerability.state`). The badge and the alert title therefore live side-by-side in the same header area but are driven by independent data. ### Prior art in the codebase The team has already faced this exact "don't conflate detection with workflow state" wording problem in an adjacent component: - `ee/app/assets/javascripts/vulnerabilities/components/resolution_badge.vue` deliberately uses **"Vulnerability remediated. Review before resolving."** as its tooltip, **avoiding the word "resolved"** because "Resolved" is a distinct workflow status value. The proposal here just extends the same convention to the resolution alert title, so the two components stop disagreeing with each other. Internal telemetry uses the same vocabulary too: the relevant internal event is named [`vulnerability_no_longer_detected_on_default_branch`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/ee/config/events/vulnerability_no_longer_detected_on_default_branch.yml). So **"No longer detected on $branch"** aligns with the docs, the existing badge component, *and* the event naming. ### How this relates to current behavior and docs Per the **Vulnerability details** documentation: - A vulnerability's **status** (Needs triage, Confirmed, Dismissed, Resolved) is a workflow state, controlled by users or by a vulnerability management policy, and does **not** automatically change just because the vulnerability is no longer detected in scans. - When a vulnerability is no longer detected in the default branch, the activity log is updated with **"No longer detected"**, but the **status remains unchanged** until it is set to *Resolved* (manually or via policy). In other words, the product intentionally separates: - **Detection state**: "no longer detected on the default branch". - **Workflow state**: still **Needs triage** until a human or policy confirms and updates it. The product *already* communicates this nuance in the alert body ("The vulnerability is no longer detected. Verify the vulnerability has been remediated before changing its status."). The problem is the **alert title**: **"Vulnerability resolved in $branch"** reads like a final state and undercuts both its own body text and the workflow badge. ### Related work - **Docs:** [Vulnerability details – status values and "Vulnerability is no longer detected"](https://docs.gitlab.com/user/application_security/vulnerabilities/) — describes the distinction between status and "no longer detected", and how vulnerability management policies can auto-resolve matching vulnerabilities. - **Tangentially related issue:** [#356843 – Improve error message when dismissing vulnerabilities on archived projects](https://gitlab.com/gitlab-org/gitlab/-/work_items/356843). That issue mentions the same banner text but in a different scenario (archived/read-only projects + permission errors on dismiss). Different scope; included only as background that this banner has been involved in confusing UX before. ### Steps to reproduce 1. Run a pipeline on the default branch that produces at least one vulnerability with status **Needs triage**. 2. Run a subsequent pipeline on the default branch where that vulnerability is no longer detected. 3. Open the vulnerability details page for that vulnerability. 4. Observe the dismissible alert at the top with title **"Vulnerability resolved in $branch"** and the status badge below showing **"Needs triage"**. 5. (Optional) Dismiss the alert and confirm it does not reappear for that vulnerability (cookie `dismissed_resolution_alerts`). ### Problem - The resolution alert title currently communicates an apparently final outcome: **"Vulnerability resolved in $branch"**. - The status badge simultaneously communicates an initial workflow state: **"Needs triage"**. - Users (especially those who don't live in the vulnerability docs) interpret this as a contradiction and are unsure whether they still need to triage or not. - The alert body already clarifies "no longer detected … verify before changing its status", but the **title overrides that nuance** for users skimming the page. - The sibling component `resolution_badge.vue` already avoids the word "resolved" for exactly this reason; the alert title is the outlier. ### Expected behavior The vulnerability details page should: - Clearly distinguish between **"no longer detected on the default branch"** and the **workflow status**, and - Avoid presenting those as conflicting messages between the alert title and the status badge. A user seeing the page should be able to immediately understand: - "The scanner no longer detects this on the default branch", **and** - "We still need to triage/update the status", **or** "This has been triaged and marked as Resolved". ### Actual behavior - Resolution alert title: **"Vulnerability resolved in $branch"** (strong implication: "this vulnerability is fixed"). - Status badge: **"Needs triage"** (strong implication: "this vulnerability is still awaiting review/action"). - The clarifying body text exists but is easy to miss next to a title that says "resolved". ### Proposal 1. **Reword the alert title in `resolution_alert.vue` to describe detection state, not final remediation.** Recommended (aligns with the docs, the `resolution_badge.vue` tooltip, and the `vulnerability_no_longer_detected_on_default_branch` internal event): - **"No longer detected on default branch"** - or, when a branch name is available: **"No longer detected on $branch"** Avoid the word **"resolved"** in the title while the workflow status is still **Needs triage** or **Confirmed**, since "Resolved" is a distinct workflow state value. 2. **Keep the existing alert body text.** The current body — *"The vulnerability is no longer detected. Verify the vulnerability has been remediated before changing its status."* — already explains the detection-vs-status distinction well and should be retained (or lightly tweaked for tone). 3. **Keep the status badge as the single source of truth for workflow state.** - The badge should continue to show **Needs triage / Confirmed / Resolved / Dismissed** as it does today. - The alert title should not use wording (e.g. "resolved") that competes with the badge. 4. **Align with docs terminology and existing component vocabulary.** Reuse the **"No longer detected"** phrase from the docs, mirror the avoid-"resolved" convention already used by `resolution_badge.vue`, and stay consistent with the `vulnerability_no_longer_detected_on_default_branch` internal event name. UI, telemetry, and documentation should all speak the same language. 5. **(Optional, out of scope) Revisit the dismiss-and-forget behavior.** The alert is currently dismissed per vulnerability via the `dismissed_resolution_alerts` cookie. Out of scope for this issue, but worth noting if UX wants to reconsider whether a detection-state message should be persistently dismissible. ### Acceptance criteria - When a vulnerability is **no longer detected** on the default branch but the status is still **Needs triage** (or **Confirmed**): - The resolution alert title does **not** say "Vulnerability resolved in $branch" / "Vulnerability resolved in the default branch". - The title clearly communicates that the vulnerability is *no longer detected on the default branch*, using terminology consistent with the docs (e.g. "No longer detected on $branch"). - The status badge continues to show **Needs triage** (or the current workflow state). - The combined alert + badge presentation is not easily interpreted as a contradiction. - When a vulnerability's status is actually **Resolved**: - The alert title and badge together present a consistent story (alert about detection, badge showing **Resolved**). ### Implementation notes - Update the i18n strings used by the `resolutionTitle` computed property in: - `ee/app/assets/javascripts/vulnerabilities/components/resolution_alert.vue` - Update / add the corresponding frontend specs for `resolution_alert.vue` to assert the new title in both branches (with and without `defaultBranchName`). - The alert is rendered by `ee/app/assets/javascripts/vulnerabilities/components/header.vue`; no change expected there, but `header_spec.js` already exercises the "no longer detected on default branch" path and should continue to pass. - Coordinate with Technical Writing if the new wording should also be reflected in the [Vulnerability details docs](https://docs.gitlab.com/user/application_security/vulnerabilities/). - No backend or data model changes are expected; this is a UI wording change. ### Suggested labels `~"group::security insights"` `~"devops::security risk management"` `~"Category:Vulnerability Management"` `~"section::sec"` `~"frontend"` `~"UX"` `~"type::bug"` `~"customer"` ### Notes - This issue is not about changing the underlying behavior of detection vs. status, nor about vulnerability management policies. It is specifically about **wording and UX** in the resolution alert so we don't present "resolved" in one place and "Needs triage" in another.