Overview

​

Vulnerabilities Page

The Vulnerabilities page serves as your central hub for viewing and managing all security vulnerabilities discovered by your connected scanners. The page is designed to help you quickly identify, prioritize, and track security issues across your organization. Vulnerabilities are displayed in a table view so you can review large volumes of findings, compare key details, sort by priority signals, and take action more efficiently.

​

What You’ll See

​

Vulnerability Views

The Vulnerabilities page organizes vulnerabilities into four views:

• Open: Vulnerabilities that still require investigation, remediation, or another action.
• All: All vulnerabilities, regardless of their current status.
• Resolved: Vulnerabilities that have been successfully resolved.
• Dismissed: Vulnerabilities that have been intentionally excluded from the active remediation workflow.

The number displayed next to each tab shows how many vulnerabilities are included in that view.

​

Open Vulnerabilities

The Open tab contains vulnerabilities that are still part of the active vulnerability management workflow. Use this view to identify vulnerabilities that require investigation, remediation, approval, mapping, or another action. The metrics displayed in this view include:

• Total number of open vulnerabilities
• Breakdown by source
• Breakdown by Risk Score
• Time to SLA

​

All Vulnerabilities

The All tab provides a complete inventory of vulnerabilities across all statuses. Use this view when you need to search across open, resolved, and dismissed vulnerabilities without switching between tabs. For resolved vulnerabilities, the SLA field is empty because the vulnerability is no longer approaching an active SLA deadline.

​

Resolved Vulnerabilities

The Resolved tab contains vulnerabilities that have completed the remediation process. In this view:

• The SLA column is displayed as Time to Remediate.
• The table shows when the vulnerability was closed.
• The metrics include the total number of resolved vulnerabilities and Mean Time to Remediate.

​

Dismissed Vulnerabilities

The Dismissed tab contains vulnerabilities that have been intentionally excluded from active remediation. Dismissed vulnerabilities are not included in active remediation queues and do not count toward the open vulnerability backlog. They remain available for visibility, reporting, and audit purposes. The metrics displayed in this view include:

• Total number of dismissed vulnerabilities
• Breakdown by source
• Breakdown by Risk Score
• Dismissal reasoning, including vulnerabilities dismissed manually or by policy

Because dismissed vulnerabilities are no longer part of the active remediation workflow, the table does not display the SLA or Remediation columns.

​

Vulnerability Metrics

At the top of the page, you’ll find summary metrics including:

• Total number of unresolved vulnerabilities
• Breakdown by source
• Breakdown by severity: Critical, High, Medium, Low
• SLA compliance breakdown

These metrics remain visible above the vulnerability table and help you understand the current state of your backlog before reviewing individual findings.

​

Vulnerability Table

Each vulnerability is displayed as a row in the table. The table shows the most important details needed to understand, prioritize, and act on each vulnerability. The table includes:

• Vulnerability: The vulnerability title and identifier. The number of results updates based on the active filters and search.
• Status: The current state of the vulnerability, such as Open, In Progress, Resolved, or Pending Action.
• Type: The type of vulnerability being addressed.
• Risk Score: The vulnerability risk score, with an info icon for additional context.
• Source: The scanner or integration that detected the vulnerability, shown with its source icon.
• Scan Origin: The affected origin of the vulnerability. This may represent a repository, image, cloud asset, or other affected resource.
• Detection Date: When the vulnerability was first discovered.
• SLA: The time remaining before the SLA deadline, or an overdue indication.
• Remediation: The associated remediation, when one exists.
• Actions: Quick links to related pull requests or tickets, when available.

​

Filtering and Search

Find specific vulnerabilities quickly using filters and search. Available filters include:

• Text Search: Search by vulnerability title or description
• Source: Filter by the scanner that detected the issue
• Type: Filter by vulnerability type
• Risk Score: Show vulnerabilities with a specific risk level
• Origin: Filter by the affected repository, image, asset, or other origin
• Issue: Filter by vulnerability identifier
• SLA: Filter by time to SLA deadline
• Status: Filter by current vulnerability status

The number of results in the table updates automatically based on the filters and search terms you apply. Available filters may vary depending on the selected vulnerability view. For example, the Dismissed view does not include the SLA filter because dismissed vulnerabilities are not part of the active remediation workflow.

​

Sorting the Table

The vulnerability table is sorted by Risk Score by default, helping you focus first on the vulnerabilities that need the most attention. You can also sort the table by:

• Risk Score
• Detection Date
• SLA

Click a sortable column header to change the sort order:

• First click sorts in ascending order.
• Second click sorts in descending order.

Only one column can be actively sorted at a time. Sorting works together with filters and search, and is applied across the full set of matching results.

​

Working with Vulnerabilities

​

Viewing Details

Click anywhere on a vulnerability row to open the vulnerability side panel. The side panel provides a focused view of the selected vulnerability. At the top of the panel, you can see the vulnerability title and key status indicators, including:

• Vulnerability type, such as SCA
• Risk score
• Current status, such as In Progress or Pending Approval
• SLA state, such as Overdue

Interactive elements in the row, such as buttons or links, open their own actions instead of opening the side panel. The side panel is organized into tabs so you can review the vulnerability context, risk, related findings, and remediation details separately.

​

Overview

Use the Overview tab to understand what was detected and where it was found. This tab includes:

• The CVE description
• Scanner source
• Repository or affected origin
• Project file
• Issue identifier
• Language
• Package name and version
• Detection date
• Upload date

Use this tab when you need to confirm the affected package, file, repository, or scanner source before reviewing risk or remediation options.

​

Risk Analysis

Use the Risk Analysis tab to understand why Backline assigned the vulnerability its current risk score. This tab includes:

• Calculated risk score
• Risk score explanation
• Risk factors, such as source severity, exploitability, exploit signals, and reachability
• CVSS base metrics
• CVE description for reference

Use this tab to understand whether the vulnerability is severe, reachable, exploitable, or associated with known exploit activity. For more details about how Backline calculates risk, see the Risk Analysis documentation.

​

Related Vulnerabilities

Use the Related Vulnerabilities tab to review other vulnerabilities connected to the selected vulnerability. The tab includes a searchable table with details such as:

• Vulnerability name or issue
• Risk score
• Status
• Type
• Available actions

Use this tab to understand whether the selected vulnerability is part of a broader remediation effort or related vulnerability group.

​

Remediation

Use the Remediation tab to review the remediation available for the selected vulnerability. When a remediation exists, this tab may include:

• Remediation summary
• Available remediation
• Packages or dependencies that will be upgraded
• Vulnerabilities addressed by the remediation
• Remediation mode, such as Auto
• Remediation status, such as Pending Approval
• Creation date
• Links to remediation steps, full remediation details, or related pull requests

Use See Remediation Steps to review the changes Backline planned or performed. Use See Full Remediation to open the full remediation view. When a pull request is available, you can open it directly from the side panel.

​

Pending Action

If a vulnerability status is Pending Action, the status appears as an actionable button. Click Pending Action to open the required action dialog and see what is needed to continue handling the vulnerability. For example, Backline may require additional mapping or user input before the vulnerability can continue through the remediation flow.

​

Pending Action for Unavailable Package Versions

Sometimes, Backline identifies a fixed version for a vulnerability, but the version is not yet available from your organization’s configured package registry, such as JFrog, Nexus, Artifactory, npm, PyPI, or Maven. When this happens, Backline pauses only the affected vulnerability and marks it as Pending Action. Other vulnerabilities continue through the normal remediation flow and can still be grouped into remediations.

Why a Vulnerability May Be Paused

A vulnerability may move to Pending Action when:

• A fixed version exists for the affected package.
• Backline cannot download that version, or a higher patched version, from your configured registry.
• The package may be temporarily blocked by a registry quarantine or approval policy.

This is different from No Fix Available. No Fix Available means there is no known fixed version for the vulnerability. Pending Action means a fix exists, but it is not currently available to download from your registry.

What Backline Does Next

Backline automatically checks the package registry every 24 hours. When the fix version becomes available, Backline moves the vulnerability out of Pending Action and includes it in a future remediation cycle. The vulnerability will not be added back to an existing remediation that has already been completed. If the package remains unavailable for 90 days, Backline moves the vulnerability to No Fix Available.

How to Resume Sooner

To allow Backline to continue sooner, update your registry policy so the fixed package version can be downloaded. For example, you can allowlist the package version or reduce the registry quarantine window.

​

Taking Action

From the vulnerability table and side panel, you can:

• Review the vulnerability overview and affected context
• Review the risk analysis and risk factors
• Review related vulnerabilities
• Navigate to the related remediation
• Review remediation steps
• Open the full remediation view
• Open associated pull requests, when available
• Open associated tickets, when available
• Review required actions for vulnerabilities in Pending Action status

The Actions column remains available at the right side of the vulnerability table, so related PR and ticket links are easy to access while reviewing the backlog.

​

Dismissing a Vulnerability

Dismiss a vulnerability when your organization has determined that it should not continue through the active remediation workflow. A vulnerability can be dismissed in two ways:

• Manually: A user dismisses the vulnerability from the Vulnerabilities page.
• By policy: Backline automatically dismisses the vulnerability because it matches an enabled Remediation Policy.

When a vulnerability is dismissed, Backline:

• Changes its status to Dismissed
• Removes it from the Open tab
• Excludes it from active remediation queues
• Records how and when the vulnerability was dismissed
• Displays it in the Dismissed tab

A vulnerability cannot be dismissed after an active remediation has started or while it is waiting for remediation approval.

​

Dismiss a Vulnerability Manually

You can dismiss an eligible vulnerability from either the vulnerability table or the vulnerability side panel.

From the Vulnerability Table

After the action is completed, a confirmation message appears and the vulnerability is removed from the current view.

From the Vulnerability Side Panel

The Dismiss Vulnerability action is displayed only when the vulnerability is eligible for dismissal and does not already have an active remediation.

​

Vulnerabilities Dismissed by Policy

Backline can automatically dismiss vulnerabilities that match an enabled Remediation Policy. For example, a policy may determine that vulnerabilities meeting specific risk, reachability, or exploitability conditions should not enter the active remediation workflow. A vulnerability dismissed by policy remains in the Dismissed tab while it continues to match the policy conditions. Users cannot manually reopen a policy-dismissed vulnerability. Backline automatically returns it to the active workflow when:

• It no longer matches the policy conditions
• A new scan changes its vulnerability context
• Updated risk analysis changes the policy result
• The applicable remediation policy is changed or disabled

Historical dismissal information is retained when the vulnerability returns to the active workflow.

​

Viewing Dismissal Details

Click a dismissed vulnerability to open its side panel and review its complete details. For dismissed vulnerabilities:

• The status is displayed as Dismissed.
• SLA information is not displayed.
• The side panel shows whether the vulnerability was dismissed manually or by policy.
• Related pull requests and Jira tickets remain available when they exist.

For a manually dismissed vulnerability, the side panel displays the user who dismissed it. For a policy-dismissed vulnerability, the side panel displays Dismissed by: Policy.

​

Reopening a Manually Dismissed Vulnerability

A manually dismissed vulnerability can be returned to the active remediation workflow. Reopening the vulnerability:

• Changes its status to Pending Remediation
• Returns it to the Open tab
• Makes it eligible for remediation
• Removes it from the Dismissed tab
• Preserves its previous dismissal information for audit and history

You can reopen a manually dismissed vulnerability from the Dismissed table or its side panel.

From the Dismissed Table

From the Vulnerability Side Panel

After the action is completed, a confirmation message appears and the vulnerability moves from the Dismissed tab to the Open tab.

​

Navigation

​

Working with Large Result Sets

The table is designed to support large vulnerability backlogs. As you scroll, additional results load automatically. The table header remains visible while you review the list, making it easier to understand each column as you move through the backlog. Long values may be shortened in the table to preserve readability. Hover over a truncated value to view the full text.

​

Understanding Risk Score Levels

​

Supported Report Types

Backline currently supports the following vulnerability report types. SCA reports from:

• Trivy - JSON format
• OSV - JSON format
• Custom Report - CSV format with YAML configuration

Image reports from:

• Custom Report - CSV format with YAML configuration
• VDR - JSON format
• AWS Inspector - JSON format

Host Vulnerability reports from:

• AWS Inspector - CSV format

Cloud Misconfig reports from:

• Custom Report - CSV format with YAML configuration

​

How to Upload a Report

​

Custom Report Configuration

When using the Custom Report option, you need to provide two files:

1. Report File: A CSV file containing your vulnerability report details.
2. YAML Config File: A configuration file that maps your CSV columns to Backline’s expected fields.

​

After Upload

Once your report is uploaded, Backline will:

1. Analyze all vulnerabilities in the report.
2. De-duplicate vulnerabilities that already exist in the system.
3. Set remediation plans for vulnerabilities where fixes are available.
4. Display the new vulnerabilities in the Vulnerabilities table.