Overview

​

Remediations Page

A remediation is a single fix that resolves one or more vulnerabilities, such as upgrading a package in a repository, rebuilding a container image, or changing a cloud resource’s configuration. Backline groups related vulnerabilities into remediations so that one change, and usually one pull request, closes all of them. The Remediations page lists every remediation in your organization so you can track progress, see what needs your attention, and open the pull requests and tickets behind each fix.

​

Remediation Modes

Every remediation runs in one of two modes:

​

What You’ll See

​

Remediation Views

The page organizes remediations into three tabs:

• Open: Remediations that are not yet resolved. This is the default view.
• All: Every remediation, regardless of status.
• Resolved: Remediations that are complete. In this view, the SLA column becomes Time to remediate.

Each tab remembers its own filters and sorting while you switch between tabs.

​

Remediation Metrics

Above the table, metrics summarize the current view:

• The number of remediations in the view
• Vulnerabilities by mode (Auto and Hybrid)
• Remediations by priority (P1, P2, P3)
• SLA violations
• Associated vulnerabilities that the remediations will resolve
• MTTR: the median time it took to resolve a vulnerability over the last 30 days, in the All and Resolved views

Click Hide analytics to collapse the metrics and give the table more room.

​

List and Radar

Switch between List and Radar next to the filters. The list is the default. The Radar plots open remediations by type and time to SLA, so you can spot urgent work at a glance. The Radar isn’t available in the Resolved view.

​

Remediations Table

Each remediation is a row in the table. The table includes:

• Remediation: The remediation title. The number next to the header is the total number of results.
• Mode: Auto or Hybrid.
• Type: The kind of fix: SCA, Container image, Host, or Cloud misconfig.
• Status: The current state of the remediation. See Remediation Statuses.
• Priority: P1, P2, or P3. See Priority.
• Origin: The repository the fix applies to. For Host and Cloud misconfig remediations, the affected asset type.
• Vulnerabilities: How many vulnerabilities the remediation resolves.
• Ticket: A link to the remediation’s ticket, when one exists.
• Creation date: When Backline created the remediation.
• SLA: The time left before the SLA deadline of the vulnerability closest to breaching it, or Overdue.
• Applications: The applications the remediation belongs to.
• Labels: Labels that describe the fix. See Labels.
• Actions: Quick links to the pull request and to what’s blocking a Pending action remediation, and a menu to create a Jira ticket.

Click any row to open the remediation side panel.

​

Sorting the Table

The table is sorted by Priority by default, so P1 remediations come first. You can also sort by Vulnerabilities, Creation date, and SLA. Click a sortable column header to cycle between ascending order, descending order, and no sorting.

​

Filtering and Search

Use the search box to find remediations by title or description. Narrow the table further with filters for mode, type, status, priority, SLA, repository, asset type, application, team, and label. The repository, asset type, application, team, and label filters suggest values as you type. Filters and sorting are saved in the page URL, so you can share a filtered view with your team.

​

Remediation Statuses

​

Labels

Labels describe what a remediation’s fix does or why it stopped, so you can tell at a glance what kind of change to expect before you open it. For example:

• Code changes: Besides upgrading packages, the pull request changes application source code.
• Base image update: The fix moves the container’s base image to a newer image or tag.
• Shared library fix: The remediation fixes an internal shared library that other remediations depend on.

Backline adds labels automatically as the remediation progresses. Labels are read-only, and once added they stay on the remediation. Labels appear in the Labels column of the table and in the side panel’s Overview tab. Use the Labels filter to find remediations with any of the selected labels.

​

Remediation Side Panel

The side panel opens when you click a remediation. Use the arrows on its side to move to the previous or next remediation in the list without closing it. At the top of the panel, you’ll see the remediation title, its mode, a short description, and its type, priority, status, and SLA. When a pull request or ticket exists, the Pull request and Ticket buttons at the bottom of the panel open it. Otherwise, click Create ticket to create a Jira ticket. The side panel has the following tabs. Some tabs appear only for certain remediations.

​

Overview

The Overview tab includes:

• Summary: What Backline changed, why, and how it verified the fix. See Remediation Summary. For Assisted fix and Pending action remediations, the summary explains what’s blocking the fix and what you can do.
• Remediation impact: The remediation’s Impact, how many vulnerabilities it resolves, its Fixability, and the remediations that depend on it.
• Context: The applications, teams, and repository or asset type, and, when available, the image, Dockerfile, release, and branch. It also shows the remediation’s labels, the remediations it depends on, and when it was created.

When a remediation is waiting on an integration, such as a container registry that rejects Backline’s credentials, a card at the top of the tab explains the problem. Backline checks again on its own and resumes the fix once the problem is solved.

​

Packages

The vulnerable packages the fix upgrades, with their current version, the version they’re upgraded to, and whether each one is a direct or transitive dependency. This tab doesn’t appear for Cloud misconfig remediations.

​

Vulnerabilities

The vulnerabilities the remediation resolves. Click a vulnerability to open its details.

​

Owners

The people responsible for the remediation. See Code Owners.

​

Remediation Playbook

Instructions for resolving the vulnerabilities at their source, and mitigations that lower the risk until you can. This tab appears when Backline has instructions for the remediation, such as for Assisted fix and Cloud misconfig remediations.

​

Remediation Plan

For Auto remediations, the steps Backline’s agents are taking to fix the vulnerabilities and the status of each step. The tab updates as the agents work.

​

Dependencies and Pending Action

Some remediations depend on another remediation before Backline can fix them. For example, an application may need an internal shared library to be fixed first. Backline identifies these relationships automatically and shows them in the Overview tab:

• Affected remediations: How many other remediations are waiting for this remediation to be completed.
• Depended remediations: How many remediations must be resolved before this remediation can continue.

Hover over the link icon next to the count to see the related remediations, and click one to open it. A remediation that is waiting for another remediation, an integration, or your input has the Pending action status. Pending action doesn’t mean the remediation failed. The summary in the Overview tab explains what it’s waiting for, and the icon in the table’s Actions column shows what’s blocking it. Its vulnerabilities also move to Pending action. Once the blocker is resolved, Backline continues the remediation.

​

Pull Requests

When Backline opens a pull request for a remediation, the remediation moves to Pending approval. Open the pull request from the table’s Actions column or the Pull request button in the side panel, and review and merge it following your standard development workflow.

• When the pull request is merged, the remediation moves to Resolved.
• When the pull request is closed without merging, the remediation moves to Failed.

To control how Backline creates pull requests, branches, and reviewers, see Git Settings.

​

Terraform PRs for Cloud Misconfigurations

Backline automatically starts a supported Terraform remediation when all affected resources map to the same root in an onboarded repository and that mapping was confirmed by a recent state read or a previous repository selection. If Backline cannot confidently identify one root, the remediation stays in Hybrid mode. You can then start it manually by selecting the repository that manages the affected resources. To start a Terraform remediation manually:

1. Open the relevant Cloud misconfig remediation.
2. Go to the Remediation playbook tab.
3. Click Open PR.
4. In Repository, select the Terraform repository that contains the configuration for the affected resource. Backline remembers your choice for the next time.
5. Click Open PR to start PR generation.

After the remediation starts, Backline will:

• Move the remediation to Auto mode.
• Change the remediation status to In progress.
• Start generating the Terraform pull request.
• Update the remediation summary.
• Show structured execution steps in the Remediation plan tab.

For Terraform changes, Backline validates the configuration first and then attempts to verify the patch against every active Terraform deployment registered for the root when the remediation starts. A deployment is one state object and its execution settings.

• If every deployment produces a safe plan, the pull request can be marked ready.
• If an optional Terraform reader role or required plan input is unavailable, Backline opens a draft pull request pending human approval.
• If the plan proves that the patch is unsafe or breaks a root that previously planned, Backline rejects the patch.

AWS plan verification is opt-in. Azure findings and unsupported AWS roots can still produce draft pull requests pending human approval without running terraform plan. See Terraform Verification for AWS for the required roles and permissions, supported cases, and security details. The Open PR button is available only while the remediation is in Hybrid mode. Once Backline starts PR generation, the button is disabled. If you do not want Backline to open a Terraform PR, follow the remediation or mitigation instructions in the Remediation playbook tab instead.

​

Code Owners

During the remediation process, Backline’s agents identify the people most likely to own the fix, based on the files it changes, recent contributors, ownership patterns, and commit history. Each candidate has a confidence score and a justification.

​

Cloud Misconfiguration Owners

Cloud misconfiguration remediations name owners from three places, and each owner shows the evidence that named them:

• The CODEOWNERS rules for the Terraform files the fix changes.
• The resource’s owner tag. Set the tag keys that name an owner in Resource Owner Tag Name on your cloud connection.
• The teams that own the resource’s application.

A tag value can be an email or a team. A team must match a team name in Backline or one of the team’s aliases, in any case. If a value matches no team, add it as an alias of the right team, and later remediations will name it. A team with a CODEOWNERS alias such as @acme/payments can be requested as a reviewer on GitHub pull requests.

​

Managing Owners

A remediation can have up to 5 assigned owners.