> ## Documentation Index
> Fetch the complete documentation index at: https://docs.backline.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Overview

> Explore and manage security vulnerabilities across your organization.

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

## Uploading Vulnerability Reports

In addition to automatically collecting vulnerabilities from connected scanners, you can manually upload vulnerability reports using the **Upload Report** action at the top of the page.

## What You'll See

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

<Tip>
  Use multiple filters together to narrow down the table. For example, you can filter for high-risk vulnerabilities from a specific source, or focus only on vulnerabilities that are close to breaching SLA.
</Tip>

The number of results in the table updates automatically based on the filters and search terms you apply.

## 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 shows more detailed information, including:

* Complete vulnerability description
* Status and explanation about the current state of the vulnerability
* Affected packages, versions, resources, or origins
* Related vulnerabilities
* Associated remediation details
* Links to external resources, such as pull requests or tickets

Interactive elements in the row, such as buttons or links, open their own actions instead of opening 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 vulnerability details and recommendations
* Open the vulnerability side panel
* Navigate to the related remediation
* 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 table, so related PR and ticket links are easy to access while reviewing the backlog.

## Navigation

<Steps>
  <Step title="Access the Page">
    Click **Vulnerabilities** in the main navigation menu.
  </Step>

  <Step title="Browse, Filter, or Search">
    Review the table, use filters, or search for a specific vulnerability.
  </Step>

  <Step title="Sort by Priority Signals">
    Sort by Risk Score, Detection Date, or SLA to focus the table on the vulnerabilities that matter most.
  </Step>

  <Step title="View Details">
    Click any vulnerability row to open the side panel and review the full vulnerability context.
  </Step>

  <Step title="Take Action">
    Use the side panel or row-level actions to open related remediations, pull requests, tickets, or required action dialogs.
  </Step>
</Steps>

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

<CardGroup cols={2}>
  <Card title="Critical" icon="skull-crossbones">
    Requires immediate attention. Default SLA: 3 days.
  </Card>

  <Card title="High" icon="circle-exclamation">
    Significant risk. Should be addressed quickly. Default SLA: 14 days.
  </Card>

  <Card title="Medium" icon="triangle-exclamation">
    Moderate risk. Plan for resolution. Default SLA: 30 days.
  </Card>

  <Card title="Low" icon="circle-info">
    Minor issues. Address as capacity allows. Default SLA: 90 days.
  </Card>
</CardGroup>

<Note>
  SLA timelines can be customized in [Settings](/settings/sla) to match your organization's security policies.
</Note>

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

## How to Upload a Report

<Steps>
  <Step title="Click Upload Report">
    At the top of the Vulnerabilities page, click the **Upload Report** button.
  </Step>

  <Step title="Select Report Type">
    Choose your report type:

    * **SCA scan**: For Software Composition Analysis vulnerability reports
    * **Image scan**: For container image vulnerability reports
  </Step>

  <Step title="Configure Based on Report Type">
    **For SCA scan:**

    * Select your source scanner
    * Upload the report file in the supported format
    * Choose the repository that this vulnerability report relates to
    * Optionally configure local repository settings

    **For Image scan:**

    * Upload the report file
    * Upload the YAML configuration file, when required
  </Step>

  <Step title="Configure Local Repository">
    If your SCA report was generated from a local environment:

    * Check the **Local Repository** checkbox
    * Specify the **path to the root of your repository** in your local environment
    * This helps Backline correctly map file paths in your scan results to your source code structure
  </Step>

  <Step title="Upload Files">
    Upload the required files based on your selected report type and source scanner.
  </Step>
</Steps>

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

<Steps>
  <Step title="Setting Up the YAML Config File">
    Click **Download Config File** in the upload dialog to see the required mapped fields.
  </Step>

  <Step title="Map Fields">
    For each required field in the config, specify the column title from your CSV file.
  </Step>

  <Step title="Verify Column Names">
    Ensure the column names in your YAML exactly match the headers in your CSV file.
  </Step>

  <Step title="Upload">
    Upload the CSV report and YAML config together.
  </Step>
</Steps>

<Tip>
  Download the sample config file before uploading your custom report to ensure you have all the required field mappings.
</Tip>

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

<Note>
  Processing large reports may take a few minutes. You'll see the vulnerabilities appear in your dashboard once processing is complete.
</Note>