> For the complete documentation index, see [llms.txt](https://docs.arnica.io/arnica-documentation/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.arnica.io/arnica-documentation/code-risks/manual-severity-changes.md). # Manual Severity Changes Manually adjust the severity of a code risk finding or an individual SCA CVE, with a required reason, an optional review workflow, and a full history on the finding. ## Summary Arnica calculates a severity for every finding it detects. Manual severity changes allow eligible users to record their own risk judgment on a finding during triage, without resorting to a dismissal or a status change as a workaround. Arnica preserves the scanner-calculated severity alongside the manually adjusted value, requires a reason for every change, and records each change in the finding timeline. Manual changes persist across subsequent scans. Severity is edited in one of two places, depending on the finding type: | Finding type | Where severity is changed | | ------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------- | | Non-SCA code findings (SAST, IaC, and other code risks) | On the finding itself, in the expanded finding header. | | SCA findings | On an individual CVE, inside the finding's vulnerabilities table. The package-level severity remains derived from the contributing CVEs. | {% hint style="info" %} Manual severity changes are enabled per tenant. Contact to have the capability turned on for your organization. {% endhint %} ## Changing the severity of a code risk finding 1. Navigate to **Risks** → **Code**. 2. Click a non-SCA finding to expand it. 3. In the expanded finding header, click the severity chip beside the status control.

Expanded finding header with the severity chip selected and the severity options listed — The severity control sits beside the status control in the expanded finding header.

4. Select the severity you want to apply. `Critical`, `High`, `Medium`, `Low`, and `Info` can be assigned manually; `Unknown` is a scanner state and cannot be selected. 5. In the **Confirm Severity Change** dialog, select a **Reason** and complete the **Details** field. Both are required.

Confirm Severity Change dialog showing the selected reason and the details text — Every severity change requires a reason category and an explanation.

6. Click **Confirm**. The finding now displays the adjusted severity, and the severity chip is marked with an edit icon to indicate that the value was set manually rather than by a scanner. ### Reason categories | Reason | When to use it | | ---------------------------- | -------------------------------------------------------------------------- | | **Business/asset context** | The business context of this asset changes the real impact of the finding. | | **Compensating control** | Another control already mitigates the finding in your environment. | | **Organization risk policy** | Your organization's risk policy rates this kind of finding differently. | | **Other** | A reason none of the categories above describe. Explain it in **Details**. | Selecting a reason other than **Other** pre-fills **Details** with a standard explanation, which you can edit or replace. **Details** accepts up to 2,000 characters. {% hint style="info" %} The reason and details are stored with the decision and rendered in the finding timeline, so they double as the history record for the change. Treat them as the explanation a future reviewer will read. {% endhint %} ### Resetting a finding to its scanner severity 1. Expand the finding and open the severity menu. An adjusted finding shows an additional **Reset to** option naming the scanner-calculated severity.

Severity menu on an adjusted finding, including the reset option that names the scanner severity — An adjusted severity is marked with an edit icon, and the menu offers a reset back to the scanner value.

2. Select **Reset to** the scanner severity. Selecting the original severity from the list of options has the same effect. 3. In the **Confirm Severity Reset** dialog, complete **Additional details** and click **Reset**.

Confirm Severity Reset dialog with the required additional details field completed — A reset requires an explanation of its own.

Once reset, the finding returns to the scanner-calculated severity and is no longer marked as manually adjusted. The full sequence of decisions remains in the timeline. ## Changing the severity of an SCA CVE SCA package severity is calculated based on the highest severity of a vulnerability inside the package, so Arnica does not offer a finding-level severity change for SCA findings — the severity control is absent from the SCA finding header. Severity is edited on the individual CVE instead, and the package severity continues to be derived from its CVEs. 1. Navigate to **Risks** → **Code** and expand an SCA finding. 2. In the vulnerabilities table, click the severity chip on the CVE row you want to adjust.

SCA vulnerabilities table with a per-CVE severity control open next to the Original Severity column — Severity is editable per CVE. The Original Severity column keeps Arnica's calculated value in view.

3. Select the new severity. The **Confirm Severity Change** dialog names the CVE being changed.

Confirm Severity Change dialog for a CVE, listing all six reason categories — CVE-level changes add Reachability and EPSS to the reason categories.

4. Select a **Reason**, complete **Details**, and click **Confirm**. CVE-level changes offer two reason categories in addition to the four above: | Reason | When to use it | | ---------------- | -------------------------------------------------------------------------------------------------- | | **Reachability** | Whether the vulnerable code is reachable from this application's execution paths changes its risk. | | **EPSS** | The likelihood of the vulnerability being exploited in the wild justifies a different severity. | An adjusted CVE shows an edit icon on its severity, and the **Original Severity** column continues to display Arnica's calculated value, so the scanner baseline stays visible next to the adjusted severity.

Vulnerabilities table row showing an adjusted CVE severity of Medium against an original severity of Critical — An adjusted CVE keeps its original severity visible for comparison.

To undo a CVE change, open the severity menu on the CVE row and select **Reset to Arnica calculated severity**. As with findings, an explanation is required. ### How CVE changes affect the finding severity The finding severity stays read-only and continues to reflect the highest-severity contributing CVE after Arnica's existing [severity reduction logic](/arnica-documentation/code-risks/software-composition-analysis-sca.md). A CVE change therefore moves the finding severity only when the edited CVE is the one that determines the rollup. When that happens, the timeline entry records both the CVE severity change and the resulting finding severity change. ## Finding severity changes in the Code Risks table The **Severity Overridden** column on the **Risks** → **Code** table reports which way a manual change moved the severity, rather than only whether one was made: | Cell | Meaning | | ---------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Red up arrow | The change **raised** the severity above the scanner value. | | Green down arrow | The change **lowered** the severity below the scanner value. | | Grey equals sign | The finding carries a manual change whose severity currently matches the scanner value. This arises on SCA findings, where a CVE change need not move the package rollup. | | Blank | The severity was never changed manually. |

Code Risks table with the Severity Overridden column showing one raised finding and several lowered findings — The Severity Overridden column shows the direction of each manual change.

The column's header filter is multi-select: **Raised**, **Lowered**, **Unchanged**, and **Not overridden** can be combined, and selected values are OR'd together. Use **Clear** to reset the filter.

Severity Overridden header filter with the Raised and Lowered checkboxes selected — Filter selections combine, so a single view can cover changes in both directions.

CSV exports of the table follow the column, writing `Raised`, `Lowered`, or `Unchanged` for adjusted findings and leaving the cell empty for the rest. {% hint style="info" %} The column reflects SCA findings as well as non-SCA findings. A CVE-level change rolls up into the parent finding's record, so an SCA finding whose rollup severity moved appears with a direction arrow. {% endhint %} ## Requiring review for severity changes By default, every role that can change severity applies the change immediately. Arnica can instead route severity changes made by the more limited roles through an approval step, using the same tenant-wide setting that governs status changes made from the Arnica UI. ### Enabling the requirement 1. Navigate to **Admin** → **Policies** and select the **Dismissal Settings** tab. 2. Select **Require Review for Status and Severity changes made from Arnica UI**. 3. Click **Save Changes**.

Dismissal Settings tab with the Require Review for Status and Severity changes made from Arnica UI checkbox selected — One checkbox governs both status changes and severity changes made from the Arnica UI.

The setting is tenant-wide and covers finding status changes, finding severity changes, CVE severity changes on SCA findings, and resets of either. ChatOps replies and pull request comment dismissals are unaffected. See [Dismissal Settings and Snooze](/arnica-documentation/code-risks/code-risk-policy-settings/dismissal-settings.md). ### Who requests and who reviews | Role | Behavior when the setting is enabled | | ------------------------------------------------------------------ | -------------------------------------------------------------------------------------------- | | **Owner**, **Admin**, **Security Reviewer** | Change severity directly, and review the requests submitted by others. | | **Collaborator**, **Collaborator-Product**, **Maintainer-Product** | Submit severity changes as requests for review. Cannot review requests, including their own. | | **Read-Only**, **Read-Only-Product** | Severity remains read-only. Cannot request or review changes. | ### Requesting a severity change A user subject to review follows exactly the same steps as any other severity change — the same severity menu, the same **Confirm Severity Change** or **Confirm Severity Reset** dialog, and the same required reason and details. On **Confirm**, Arnica records the request instead of applying it and confirms that the change was submitted for review. While a request is pending: * The severity is unchanged. The finding keeps its current severity everywhere — the finding header, the **Severity Overridden** column, reports, and policy evaluation. * The finding's status moves to **Pending Review**, and the request is listed on the finding's **Timeline** tab. * Only one request can be pending per target. A second request for the same finding, or for the same CVE, is rejected until the first one is decided.

Finding header showing the unchanged severity and a Pending Review status, with the submitted request listed on the timeline and no decision controls — The requester sees the submitted request on the timeline, the severity untouched, and the status on Pending Review. The Approve and Deny controls are shown only to reviewers.

{% hint style="info" %} **Pending Review** is the same status used for dismissal reviews. Filter the **Status** column on **Risks** → **Code** by **Pending Review** to find the findings that are waiting on either kind of decision. {% endhint %} ### Approving or denying a request 1. Open the finding and select the **Timeline** tab. 2. Locate the pending request. It shows the current severity, the requested severity, the CVE identifier for a CVE-level request, and **Approve** and **Deny** buttons. 3. Click **Approve** or **Deny**. 4. In the **Confirm Resolution** dialog, optionally add a comment, then click **Confirm**.

Finding timeline showing a pending severity change request with the current and requested severity chips and the Approve and Deny buttons — A pending request sits at the top of the timeline. The finding keeps its current severity, and its status reads Pending Review until a reviewer decides.

| Decision | Result | | ----------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Approve** | Arnica applies the requested change or reset. It is recorded as if the reviewer had made it, so the standard severity change entry is written to the timeline alongside the decision. | | **Deny** | The severity is left as it is. The request is closed, and the reason the requester supplied remains in the timeline. | Once no requests are left pending, the finding returns to the status it held before the request — usually `Open`. A finding that also has a status change awaiting review stays in **Pending Review** until that decision is made as well. ### When a request can no longer be applied * **The severity moved in the meantime.** If someone else changed or reset the severity after the request was submitted, approving it fails and the reviewer is told that the severity changed after the request was made. Denying still works, and the requester can submit a fresh request against the current value. * **The override is already gone.** A reset can only be requested, and only applied, while the target is still manually adjusted. * **The CVE is no longer in the finding.** If the package is updated and a CVE drops out of the finding, Arnica automatically declines any request pending for that CVE and records the decision against `system` with the reason `CVE no longer present in finding`. ## Finding history Every severity change — on a finding or on a CVE, an adjustment or a reset — appends an entry to the **Timeline** tab of the finding, recording the acting user, the timestamp, the severity transition, and the reason. Requests submitted for review and the decisions taken on them are recorded the same way, so a change that went through review keeps both the request and its outcome on the record.

Finding timeline entry recording a severity change from Critical to High, the acting user, and the reason — The timeline preserves who changed the severity, when, and why.

Timeline entries read as follows: * **Finding severity adjusted** — the transition between the two severities, the acting user, and the reason category with its details. * **CVE severity adjusted** — the CVE identifier and its package, the CVE severity transition, the resulting finding severity change when the rollup moved, and the reason. * **Reset** — the transition back to the scanner or Arnica-calculated severity, plus the explanation supplied for the reset. * **Severity change requested** — the target (the finding, or a named CVE), the transition from the current severity to the requested one, the requesting user, and the reason. A pending request carries **Approve** and **Deny** buttons for reviewers. * **Review decision** — whether the reviewer accepted or rejected the request, who requested it, the severity that was requested, and any comment the reviewer added. An approved request also writes its own adjusted or reset entry, attributed to the reviewer. ## Permissions Manual severity changes are available to the same roles that can change a finding's status: **Owner**, **Admin**, **Security Reviewer**, **Collaborator**, **Collaborator-Product**, and **Maintainer-Product**. The **Read-Only** and **Read-Only-Product** roles see the severity as read-only. Product-scoped roles can only change the severity of findings inside their assigned products. A finding outside the caller's products is treated as not found. When **Require Review for Status and Severity changes made from Arnica UI** is enabled, the **Collaborator**, **Collaborator-Product**, and **Maintainer-Product** roles submit severity changes for approval instead of applying them directly. See [Requiring review for severity changes](#requiring-review-for-severity-changes). See [Role Based Access Control (RBAC)](/arnica-documentation/security/role-based-access-control-rbac.md) for the full role definitions. ## Related * [🧩 Software Composition Analysis (SCA)](/arnica-documentation/code-risks/software-composition-analysis-sca.md) — how Arnica calculates and reduces package severity. * [🎮 Role Based Access Control (RBAC)](/arnica-documentation/security/role-based-access-control-rbac.md) — role definitions and permissions. * [Dismissal Settings and Snooze](/arnica-documentation/code-risks/code-risk-policy-settings/dismissal-settings.md) — the tenant-wide setting that sends status and severity changes through review, plus the other controls over triage decisions.