SLA Branches
Understand how SLA branches define where Arnica starts remediation timers and scopes routine code risk scans.
Summary
An SLA branch is a branch that Arnica treats as important enough to hold security findings to a remediation timeline. When Arnica detects a finding on an SLA branch, it starts the finding's SLA Start clock. SLA policies use that clock to determine whether the finding is within or past the allowed remediation window.
Branches that are not SLA branches are still scanned during real-time development workflows and their findings remain visible. Those findings do not start an SLA clock until Arnica detects the same risk on an SLA branch.
If no SLA branches are configured for a repository, Arnica automatically treats the repository's default branch as its SLA branch.
When to add SLA branches
The default branch is usually enough for repositories that ship only from main or master. Add SLA branches when additional long-lived branches also need remediation tracking and routine scanning, such as:
Release or maintenance branches that are actively shipped to production, such as
release/1.0orrelease/2.0.Environment branches that represent deployed code, such as
stagingorproduction.Any branch where findings should count toward SLA reporting and policy enforcement.
Short-lived feature branches are usually not SLA branches because they are often deleted or merged quickly.
How SLA tracking works
SLA Start
A finding's SLA clock starts the first time Arnica detects that finding on an SLA branch. Arnica shows this as the finding's SLA Start date, and the finding history includes an event indicating that the finding was detected on a branch with an associated SLA.
When a risk moves from a feature branch into an SLA branch, the clock starts the next time Arnica detects the risk on the SLA branch, such as the next scan or push on that branch. The SLA clock does not retroactively count the time the risk spent on the feature branch.
SLA TTR
SLA TTR means SLA Time to Remediation. It measures the time between SLA Start and when the finding is resolved. Use SLA TTR to understand how quickly teams remediate risks on the branches that matter most.
Multiple SLA branches
If the same vulnerability exists on multiple SLA branches, Arnica tracks it independently per SLA branch. Each branch has its own finding record, SLA clock, and remediation status.
This means fixing the issue on one SLA branch does not automatically resolve it on another branch. The finding is resolved on each SLA branch only after the fix reaches that branch and Arnica detects the updated state.
How SLA branches affect scans
Routine code security scans focus on SLA branches. When Arnica runs scheduled scans for a repository, it scans the configured SLA branches. If no SLA branches are configured, Arnica scans the repository's default branch.
Each SLA branch scan includes Arnica's code security coverage for SAST, SCA, Infrastructure as Code, and secrets detection.
Initial inventory discovery may catalog additional active or protected branches. Routine ongoing code security scans are scoped to SLA branches.
When you add a new SLA branch, Arnica automatically scans that branch so findings can be detected and SLA tracking can begin.
Removing an SLA branch
When you remove a branch from SLA tracking, or when the branch is deleted from the repository:
Open findings that were tracked on that branch are dismissed automatically with the reason Branch is no longer under SLA.
The SLA clock for those findings is cleared.
If you re-add the branch later and the same risks are still present, Arnica reopens those findings automatically.
SLA policies
SLA branches work with SLA policies. In an SLA policy, you define the allowed remediation window in days. A finding Exceeds SLA when the time since SLA Start is greater than the configured window.
To enforce SLAs, create or edit a policy under Admin > Policies and configure it with:
Trigger: Routine scan - the policy is evaluated during Arnica's routine scheduled scans of SLA branches.
Condition: Finding - Exceeded SLA - the policy acts on findings whose time since SLA Start is past the configured remediation window.
Then add the actions you want Arnica to take when a finding exceeds its SLA, such as notifying an owner or channel.
Only findings with an SLA clock can exceed SLA. Findings that never reach an SLA branch do not trigger SLA policy actions.
Where to see SLA data
You can review SLA data in:
Code risks pages - SLA-tracked findings show SLA Start and SLA TTR values. You can also filter findings by SLA status.
Finding history - the timeline shows when the finding first reached an SLA branch.
Dashboards and trends - SLA-tracked findings feed remediation reporting across products and repositories.
Configure SLA branches
To configure SLA branches for a repository:
Navigate to Inventory > Products.
Open the relevant product.
Select the Assets tab.
Expand the repository.
In the SLA Branches column, click Click to add SLA branch.
Enter the branch name and press Enter.
To remove a branch, click the X on its branch tag.
Changes are saved automatically.
SLA branch names are case-sensitive and must match the repository branch name exactly. For example, Release/1.0 and release/1.0 are different branch names.
You can configure up to 10 SLA branches per asset.
If you have not added custom SLA branches, the repository's default branch appears as a locked SLA branch. After you add explicit SLA branches, those branches replace the automatic default in the product configuration.
If the same repository is assigned to multiple products, Arnica combines the SLA branches configured across those products. A branch configured as an SLA branch in any product is treated as an SLA branch for that repository.
Custom SLA branch configuration may depend on your Arnica plan. If the option is unavailable, contact Arnica support.
Configure SLA branches by API
You can also configure SLA branches programmatically through the Arnica API. Use the Arnica API Swagger to find the repository asset update operation and set the repository asset's SLA branches list.
FAQ
Do I have to configure SLA branches?
No. By default, Arnica treats each repository's default branch as an SLA branch. Configure SLA branches only when you need SLA tracking on additional long-lived branches or branches other than the default branch.
Which branches does Arnica scan on an ongoing basis?
Routine scheduled code security scans run on SLA branches. If no custom SLA branches are configured, routine scans run on the repository's default branch.
Will I lose findings on feature branches if they are not SLA branches?
No. Findings on non-SLA branches remain visible. They do not start an SLA clock until Arnica detects the same risk on an SLA branch.
Why do I see the same vulnerability on more than one branch?
Each SLA branch is tracked independently. The same vulnerability can appear once per SLA branch, with a separate SLA clock and remediation status for each branch.
When does the SLA clock start?
The SLA clock starts the first time Arnica detects the finding on an SLA branch. If the risk is merged from a feature branch, the clock starts on the next detection event for the SLA branch, not at the moment the merge occurs.
Last updated
Was this helpful?