🎚️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.

Manual severity changes are enabled per tenant. Contact [e-mail] to have the capability turned on for your organization.

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.

The severity control sits beside the status control in the expanded finding header.

1. 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.

2. In the Confirm Severity Change dialog, select a Reason and complete the Details field. Both are required.

Every severity change requires a reason category and an explanation.

1. 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.

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.

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.

An adjusted severity is marked with an edit icon, and the menu offers a reset back to the scanner value.

1. Select Reset to the scanner severity. Selecting the original severity from the list of options has the same effect.

2. In the Confirm Severity Reset dialog, complete Additional details and click Reset.

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.

Severity is editable per CVE. The Original Severity column keeps Arnica's calculated value in view.

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

CVE-level changes add Reachability and EPSS to the reason categories.

1. 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.

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. 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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

See Role Based Access Control (RBAC) for the full role definitions.

Related

• 🧩 Software Composition Analysis (SCA) — how Arnica calculates and reduces package severity.

• 🎮 Role Based Access Control (RBAC) — role definitions and permissions.

• Dismissal Settings and Snooze — the tenant-wide setting that sends status and severity changes through review, plus the other controls over triage decisions.