> For the complete documentation index, see [llms.txt](https://docs.interlynk.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.interlynk.io/product-guides/security-and-compliance/vulnerabilities.md).

# Vulnerabilities

Vulnerability management is the process of identifying, triaging, and remediating known security issues in your software supply chain. Interlynk maps vulnerabilities to components in your SBOMs using package identifiers (PURL, CPE), enriches them with exploitability data (EPSS, KEV), and provides VEX-based disposition tracking to document your organization's response.

***

## Overview

When an SBOM is uploaded and vulnerability scanning is enabled, the platform automatically:

1. Extracts identifiers (PURL, CPE) from each component.
2. Queries multiple vulnerability databases for known issues.
3. Checks whether the component's version falls within affected version ranges.
4. Creates vulnerability records linking components to CVEs.
5. Enriches records with EPSS scores, KEV status, and CWE classifications.

Vulnerability data is scoped per Product, Environment, and Version. Each vulnerability record tracks its VEX status, justification, custom field values, and remediation history.

## Architecture

```
SBOM Upload
  └── Component Extraction
        └── Identifier Matching (PURL / CPE)
              └── Vulnerability Database Lookup
                    ├── NVD (National Vulnerability Database)
                    ├── GitHub Security Advisories
                    ├── OSV (Open Source Vulnerabilities)
                    └── Ecosystem-specific databases
                          └── Affected Version Range Check
                                └── Vulnerability Record
                                      ├── CVSS Score + Vector
                                      ├── EPSS Score + Percentile
                                      ├── KEV Status
                                      ├── CWE Classification
                                      ├── VEX Status + Justification
                                      └── Custom Fields
```

**Interactions:**

* **Policies** — trigger on vulnerability severity, EPSS score, KEV status, VEX status, and custom fields.
* **Automation Rules** — auto-assign VEX status or trigger actions based on vulnerability attributes.
* **Ticketing** — Jira and Linear tickets can be created from vulnerability details.
* **Notifications** — Slack, Teams, and email alerts for new or changed vulnerabilities.
* **Health Scoring** — open vulnerabilities reduce component and Product health scores.
* **Compliance** — VEX disposition status affects compliance evaluations (NTIA, FDA, CRA).

***

## Viewing Vulnerabilities

### Product-Level View

1. Navigate to the **Products** page and select a Product.
2. Select an Environment and Version.
3. Click the **Vulnerabilities** tab.

The vulnerability list displays:

| Column         | Description                                                                                        |
| -------------- | -------------------------------------------------------------------------------------------------- |
| **CVE ID**     | Vulnerability identifier (e.g., CVE-2024-1234)                                                     |
| **Component**  | Affected component name and version                                                                |
| **Severity**   | Critical, High, Medium, Low                                                                        |
| **CVSS**       | Base CVSS score (0.0–10.0)                                                                         |
| **EPSS**       | Exploit prediction probability (0.0–1.0)                                                           |
| **KEV**        | Whether the vulnerability is in a known exploited vulnerabilities catalog (CISA KEV or ENISA EUVD) |
| **VEX Status** | Current disposition (Affected, Not Affected, Under Investigation, Fixed)                           |

For CPE-matched vulnerabilities, the detail view also shows the **fixed version** and **last-affected version** when available. When the last-affected version is empty, the vulnerability is shown as "Affected before \<fix>".

{% hint style="info" %}
Vulnerability scan status updates live. As a scan runs, counts in the versions table and the SBOM vulnerabilities view refresh in place — no manual reload is needed. Vulnerability stat badges are not clickable while a scan is in progress.
{% endhint %}

### Organization-Level View

The **Vulnerabilities** page in the main navigation provides a cross-product view of all vulnerabilities across the organization, with filtering by severity, VEX status, KEV inclusion, EPSS range, retracted status, and product. Component vulnerabilities can also be filtered by label.

**Retracted filter:** Retracted vulnerabilities can be filtered out of component and SBOM vulnerability lists so withdrawn advisories don't clutter triage.

**EPSS range filter:** Set a minimum and maximum EPSS value using the custom range control to isolate vulnerabilities at a specific exploitation probability. For example, set `0.5–1.0` to see only high-exploitation-probability issues.

**Dashboard impact badges:** The severity badges in the dashboard's vulnerability impact summary are clickable. Clicking a badge (Critical, High, Medium, or Low) opens the product vulnerability list pre-filtered to that severity.

***

## Severity and Scoring

### CVSS (Common Vulnerability Scoring System)

| Severity     | Score Range |
| ------------ | ----------- |
| **Critical** | 9.0–10.0    |
| **High**     | 7.0–8.9     |
| **Medium**   | 4.0–6.9     |
| **Low**      | 0.1–3.9     |

Each vulnerability includes a CVSS v3.1 base score and vector string (e.g., `CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H`).

### EPSS (Exploit Prediction Scoring System)

EPSS provides a probability (0–1) that a vulnerability will be exploited in the wild within 30 days. The percentile ranks the vulnerability relative to all scored CVEs.

| EPSS Range | Interpretation                                              |
| ---------- | ----------------------------------------------------------- |
| > 0.5      | Very high exploitation probability — prioritize immediately |
| 0.1–0.5    | High exploitation probability — investigate promptly        |
| 0.01–0.1   | Moderate exploitation probability                           |
| < 0.01     | Low exploitation probability                                |

### KEV (Known Exploited Vulnerabilities)

A known exploited vulnerability is one confirmed to be actively exploited in the wild. KEV-listed vulnerabilities should be remediated with the highest priority regardless of CVSS score.

The KEV flag draws on two feeds:

| Feed           | Source                                                                                        |
| -------------- | --------------------------------------------------------------------------------------------- |
| **CISA KEV**   | U.S. Cybersecurity and Infrastructure Security Agency Known Exploited Vulnerabilities catalog |
| **ENISA EUVD** | European Union Agency for Cybersecurity, EU Vulnerability Database known-exploited entries    |

A vulnerability is flagged as KEV if it appears in either feed, so the two catalogs are unioned rather than treated separately. The KEV filter and the KEV policy subject both operate on this combined flag.

{% hint style="info" %}
If one feed is temporarily unavailable, entries from the other are still applied. A feed outage narrows KEV coverage for that refresh but does not drop the entries the other feed supplied.
{% endhint %}

### CWE (Common Weakness Enumeration)

CWE classifies the root cause of a vulnerability (e.g., CWE-79: Cross-site Scripting, CWE-89: SQL Injection). This helps identify patterns in vulnerability types across your portfolio.

### Custom Scoring Adjustments

Administrators can adjust vulnerability scoring per component:

* **Adjusted CVSS Score** — override the base CVSS score based on organizational context.
* **Temporal Vector** — apply temporal metrics (exploit maturity, remediation level).
* **Environmental Vector** — apply environmental metrics specific to your deployment context.

### Editing CVSS Scores

CVSS scores can be edited directly from the vulnerability view for any organization:

1. Navigate to the vulnerability detail view.
2. Click the **Edit** action on the CVSS score field (available in the expanded vulnerability row or detail panel).
3. Enter the adjusted score and optionally provide a CVSS vector string.
4. Save.

The adjusted score is used by policy rules, compliance calculations, and all downstream reporting. The original base score is preserved and visible alongside the adjusted value.

For custom field configuration, see [Administration: Vulnerability Custom Fields](/administration/vulnerability-custom-fields.md).

***

## VEX Status (Vulnerability Disposition)

The [Vulnerability Exploitability eXchange (VEX)](https://www.cisa.gov/resources-tools/resources/minimum-requirements-vulnerability-exploitability-exchange-vex) standard defines how to declare the exploitability status of a vulnerability in your specific context.

### Status Values

| Status                  | Description                                        | When to Use                                                                            |
| ----------------------- | -------------------------------------------------- | -------------------------------------------------------------------------------------- |
| **Affected**            | The vulnerability applies and requires remediation | Component is in use, vulnerable code is reachable, no mitigations exist                |
| **Not Affected**        | The vulnerability does not apply                   | Component is present but the vulnerability is not exploitable (justification required) |
| **Under Investigation** | Applicability is being assessed                    | Newly discovered vulnerability, awaiting analysis                                      |
| **Fixed**               | The vulnerability has been remediated              | Component updated, patch applied, or workaround implemented                            |

### Not Affected Justifications

When setting a vulnerability to **Not Affected**, a justification is required:

| Justification                                         | Description                                                                         |
| ----------------------------------------------------- | ----------------------------------------------------------------------------------- |
| **Component Not Present**                             | The vulnerable component is not actually present in the deployed build              |
| **Vulnerable Code Not Present**                       | The specific vulnerable code path is not included                                   |
| **Vulnerable Code Not in Execute Path**               | The vulnerable code exists but cannot be reached at runtime                         |
| **Vulnerable Code Cannot Be Controlled by Adversary** | The vulnerable code is present and reachable but cannot be exploited by an attacker |
| **Inline Mitigations Already Exist**                  | Compensating controls prevent exploitation                                          |

{% hint style="warning" %}
All "Not Affected" dispositions must include a justification. This is required for VEX compliance and provides audit evidence for compliance frameworks.
{% endhint %}

***

## Managing Vulnerability Status

### Setting Status for a Single Vulnerability

1. Navigate to the Version's **Vulnerabilities** tab.
2. Click on a vulnerability to open its detail view.
3. Select the VEX status from the dropdown.
4. If **Not Affected**, select the justification.
5. Optionally add a response description.
6. Save.

### Acting on Several Vulnerabilities at Once

Select vulnerabilities in the list using the row checkboxes. A bulk action bar floats above the table while a selection is active, showing how many rows are selected and the actions available for them. Each action is labeled, so you can tell what a bulk action will do before applying it.

Clearing the selection dismisses the bar. Filtering the list also clears the selection, so a bulk action never applies to rows that have scrolled out of the current filter.

### Importing Status from Previous Versions

When "Copy VEX Across Versions on Import" is enabled in Environment Settings, VEX dispositions from previous Versions carry forward automatically to new uploads. This eliminates re-triaging the same vulnerabilities.

#### Recovering VEX for the Same Version

When an automatic same-version VEX copy was incomplete, use **Copy VEX from this version** to recover the VEX data on demand. A review notification confirms when the copy completes.

### Setting Status Across Multiple Versions

Apply a disposition to the same vulnerability across all Versions of a Product:

1. Open the vulnerability detail view.
2. Select **Apply to All Versions**.
3. Confirm the action.

### Setting Status Across Multiple Products

Apply a disposition organization-wide for a specific CVE:

1. Navigate to the organization-level Vulnerabilities page.
2. Select the vulnerability.
3. Apply the VEX status across all affected Products.

### Custom Vulnerabilities

In addition to automatically discovered vulnerabilities, you can create custom vulnerability records:

1. Navigate to the Version's **Vulnerabilities** tab.
2. Click **Add Custom Vulnerability**.
3. Enter the vulnerability details (ID, description, severity, affected component).
4. Save.

Custom vulnerabilities are useful for tracking internally discovered issues or vulnerabilities not yet published in public databases.

***

## Importing Third-Party VEX Documents

When a supplier or upstream project provides a VEX document, the **VEX Import Wizard** bulk-applies its statements to the matching components in your SBOM, so you do not have to re-triage vulnerabilities the supplier has already assessed.

### Supported Formats

VEX documents in **JSON** or **XML**, up to 10 MB, in any of four formats:

| Format        | Notes                                                                                        |
| ------------- | -------------------------------------------------------------------------------------------- |
| **CycloneDX** | VEX-only documents, or combined BOM/VDR documents with embedded `vulnerabilities[].analysis` |
| **OpenVEX**   | JSON                                                                                         |
| **CSAF**      | JSON                                                                                         |
| **SPDX 3.0**  | Standalone VEX documents                                                                     |

### Running an Import

The wizard has four steps: **Upload → Select Products → Review → Result**.

1. Navigate to the Version's **Vulnerabilities** tab.
2. From **Import Statuses**, choose **Import VEX**.
3. **Upload** — drop or select the VEX document. The wizard analyzes it and shows a preview summary (document format, spec version, timestamp, statement count, product, supplier, authors, tools) before you continue. If the document's scope does not match this SBOM, the preview flags it. Click **Next**.
4. **Select Products** — a VEX document can carry statements about several products. Pick the affected products whose statements should be applied to this SBOM; the step shows a statement count per product and a running total for your selection. When the document names one affected product or none at all, the wizard skips this step and imports the whole document.
5. **Review** — statements are grouped by how they matched the SBOM's components, into **Matched**, **Conflicts**, **Ambiguous**, and **Unmatched** tabs, each with a count. Select the entries you want to apply, then click **Apply VEX**.
6. **Result** — a summary shows how many dispositions were **Applied**, **Skipped**, and (if any) **Errors**. Click **Done**.

### Resolving Conflicts

A statement lands in the **Conflicts** tab when the vulnerability already carries a disposition in Interlynk and the imported statement proposes a different status. Nothing is overwritten silently.

Each conflict row shows the existing status and the proposed status side by side. Selecting the row marks it **Overwrite**; leaving it unselected marks it **Keep existing**, which skips the statement and preserves your triage.

Statements that merely restate the existing status are not treated as conflicts.

{% hint style="info" %}
The Environment setting **Overwrite Existing VEX Dispositions** decides how conflicts arrive in the Review step. With it off (the default), conflicting entries start unselected, so you opt each one in. With it on, they start selected to overwrite. Either way you can change any row before applying. See [Product Settings](/product-guides/sbom-management/products.md#product-settings).
{% endhint %}

### How Statements Are Matched

The importer maps each VEX statement onto components using, in order:

| Strategy             | Basis                                                               |
| -------------------- | ------------------------------------------------------------------- |
| **SPDX IRI**         | SPDX 3.0 element IRI matched against the target SBOM's own elements |
| **Identity**         | PURL, CPE, or component name and version                            |
| **BOM-Link**         | CycloneDX `bom-ref` resolved against the target SBOM                |
| **Vulnerability ID** | Fallback when the statement carries no usable component reference   |

If a statement has a missing or blank affects reference, it falls through to vulnerability-ID matching rather than failing the whole import. A vulnerability ID that matches more than one component is reported as **Ambiguous**, and you pick the intended component in the Review step.

### Import History

Each import is recorded in the **VEX Import History** drawer for the SBOM, with per-status counts (applied, skipped, error) so you can audit what a given document changed.

***

## Exporting VEX Documents

To share your dispositions without shipping the full SBOM, export VEX on its own.

1. Navigate to the Version and click the **Download** button.
2. Choose **VEX**.
3. Select a specification: **CycloneDX** (1.7) or **SPDX** (3.0.1).
4. Click **Download**. The file is written as JSON, named `<product>-<version>-vex.cdx.json` or `<product>-<version>-vex.spdx.json`.

The VEX option requires vulnerability edit access and is not available on the Free tier or through ShareLynk links. To ship VEX data inside the SBOM instead, use the **SBOM** download and select the **Vulnerability Status** option. See [Downloading SBOMs](/product-guides/sbom-management/versions.md#downloading-sboms).

***

## Querying Vulnerabilities

### Via CLI

```bash
# List vulnerabilities for a product
pylynk vulns --prod "my-backend-service"

# Filter by environment
pylynk vulns --prod "my-backend-service" --env "production"

# Include vulnerability and VEX details
pylynk vulns --prod "my-backend-service" --vuln-details --vex-details

# Custom columns
pylynk vulns --prod "my-backend-service" \
  --columns "id,component_name,component_version,severity,cvss,epss,status,justification"

# Export for compliance reporting
pylynk vulns --prod "my-backend-service" --env "production" \
  --vuln-details --vex-details --output csv > vuln-report.csv

# List all available column names
pylynk vulns --list-columns
```

| Parameter        | Required | Default     | Description                                                   |
| ---------------- | -------- | ----------- | ------------------------------------------------------------- |
| `--prod`         | Yes      | —           | Product name                                                  |
| `--env`          | No       | `default`   | Environment name                                              |
| `--vuln-details` | No       | Off         | Include vulnerability metadata (CVSS vector, CWE, references) |
| `--vex-details`  | No       | Off         | Include VEX status details (justification, response)          |
| `--columns`      | No       | Default set | Comma-separated list of output columns                        |
| `--list-columns` | No       | —           | Display all available column names                            |
| `--output`       | No       | `table`     | Output format: `table`, `json`, `csv`                         |

### Via API

```bash
curl -X POST https://api.interlynk.io/lynkapi \
  -H "Authorization: Bearer $INTERLYNK_SECURITY_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "query": "query { organization { projectGroups(first: 5) { nodes { name projects { nodes { name sboms(first: 1) { nodes { id componentVulns(first: 10) { nodes { vuln { vulnId sev cvssScore } component { name version } } } } } } } } } } }"
  }'
```

### Via MCP

```
list_vulnerabilities       # List vulnerabilities with severity/VEX/KEV filtering
get_vulnerability          # Get vulnerability by CVE ID or UUID
search_vulnerabilities     # Search vulnerabilities across all products
```

***

## Issue Tracker Integration

Vulnerabilities can be linked to external issue trackers for remediation tracking:

### Jira Integration

1. Ensure the Jira integration is configured (see [Administration: Jira](/administration/jira.md)).
2. Open a vulnerability detail view.
3. Click **Create Jira Ticket**.
4. The ticket is created with vulnerability details pre-populated.
5. Ticket status is synced bidirectionally — updates in Jira are reflected in Interlynk.

### Linear Integration

1. Ensure the Linear integration is configured (see [Administration: Linear](/administration/linear.md)).
2. Open a vulnerability detail view.
3. Click **Create Linear Issue**.
4. The issue is created with vulnerability details.

### Bulk Ticket Actions

Issue-tracker actions are also available on a multi-row selection, from the bulk action bar described in [Acting on Several Vulnerabilities at Once](#acting-on-several-vulnerabilities-at-once).

These actions stay visible when no tracker is connected, and when the feature is not included in your plan, rather than disappearing from the bar. Selecting one in that state tells you what is missing, so the path to enabling ticketing is discoverable from the place you would use it.

{% hint style="info" %}
Custom field values can flow into Jira tickets when custom field mappings are configured. See [Vulnerability Custom Fields](/administration/vulnerability-custom-fields.md) for details.
{% endhint %}

***

## Downloading Vulnerability Data

Vulnerability data can be included in SBOM downloads:

```bash
# Download SBOM with embedded vulnerability data
pylynk download --prod "my-backend-service" --env "production" --ver "v1.2.0" \
  --out-file enhanced-sbom.json \
  --vuln true

# Download with vulnerability and support status
pylynk download --prod "my-backend-service" --env "production" --ver "v1.2.0" \
  --out-file full-sbom.json \
  --vuln true \
  --include-support-status
```

{% hint style="info" %}
Vulnerability data in downloaded SBOMs includes VEX status and justifications in CycloneDX, and in **SPDX 3.0** exports, which round-trip VEX and support status. SPDX 2.x downloads include vulnerability references but not VEX data.
{% endhint %}

***

## Permission Matrix

| Permission                      | Admin | Operator | Viewer |
| ------------------------------- | :---: | :------: | :----: |
| View vulnerabilities            |   ✓   |     ✓    |    ✓   |
| View feeds                      |   ✓   |     ✓    |    ✓   |
| Manage feeds                    |   ✓   |     ✓    |    —   |
| Manage lists                    |   ✓   |     ✓    |    —   |
| Manage custom fields            |   ✓   |     ✓    |    —   |
| Edit vulnerabilities            |   ✓   |     ✓    |    —   |
| View SBOMs (vulnerability data) |   ✓   |     ✓    |    ✓   |

View Vulnerabilities gates VEX and vulnerability exports, the download options on vulnerability tables, and the Copy VEX action. It is not granted automatically to custom roles. See [Role Management](/administration/role-management.md) for the full permission list.

***

## Security Warnings

{% hint style="warning" %}
**Components without PURL or CPE identifiers will not be matched against vulnerability databases.** This creates blind spots in your vulnerability posture. Ensure SBOM generation tools produce identifiers for all components.
{% endhint %}

{% hint style="warning" %}
**VEX status is lost on re-upload unless retention is enabled.** Enable "Retain Vulnerability Status with Version" and "Copy VEX Across Versions on Import" in Environment Settings to preserve triage decisions.
{% endhint %}

{% hint style="warning" %}
**Custom CVSS adjustments override the original severity.** Misconfigured adjustments can suppress critical vulnerabilities. Review all custom scoring changes periodically.
{% endhint %}

{% hint style="warning" %}
**KEV-listed vulnerabilities are actively exploited.** These should be remediated with the highest priority regardless of CVSS score. Configure policies to fail on KEV-listed vulnerabilities.
{% endhint %}

***

## Common Misconfigurations

| Issue                                    | Symptom                                                   | Fix                                                                                          |
| ---------------------------------------- | --------------------------------------------------------- | -------------------------------------------------------------------------------------------- |
| Vulnerability scanning disabled          | No vulnerabilities appear after upload                    | Enable "Run Vulnerability Scan" in Environment Settings                                      |
| Components lack identifiers              | Known-vulnerable components show no vulnerabilities       | Improve SBOM tooling to produce PURL/CPE identifiers                                         |
| VEX status not preserved across versions | Triage work lost on each upload                           | Enable "Retain Vulnerability Status with Version" and "Copy VEX Across Versions on Import"   |
| EPSS/KEV data missing                    | EPSS and KEV columns empty                                | EPSS/KEV enrichment is automatic; the vulnerability may be too new or not in the KEV catalog |
| Overly broad automation rules            | Non-critical vulnerabilities generating excessive tickets | Narrow rule conditions — target specific severities, EPSS thresholds, or KEV status          |
| Custom CVSS override too low             | Critical vulnerability not flagged by policies            | Review custom scoring adjustments; reset to base CVSS if the override is unjustified         |
| No Jira integration configured           | "Create Ticket" button not available                      | Configure the Jira integration in Settings > Organization > Integrations > Connections       |
| "Not Affected" without justification     | Compliance audit findings                                 | All "Not Affected" dispositions require a justification — review and add missing ones        |

***

## Recommended Best Practices

* **Prioritize by exploitability, not just severity.** Use EPSS scores and KEV status to focus on vulnerabilities most likely to be exploited. A high-EPSS, KEV-listed medium-severity vulnerability may be more urgent than a critical vulnerability with no known exploit.
* **Triage systematically.** Establish a workflow: new vulnerabilities → under investigation → affected/not affected → fixed. Record justifications for all "not affected" dispositions.
* **Use environment-aware prioritization.** A vulnerability in a `production` Environment is more urgent than the same vulnerability in `development`. Configure policies accordingly.
* **Enable VEX retention settings** to avoid re-triaging the same vulnerabilities when SBOMs are updated.
* **Use Custom Fields** to track organization-specific metadata (e.g., assigned engineer, remediation deadline, business impact assessment).
* **Review KEV-listed vulnerabilities immediately.** These are confirmed to be actively exploited and should be remediated with the highest priority.
* **Automate ticket creation** for vulnerabilities that match your triage thresholds (e.g., critical severity + KEV = auto-create Jira ticket).
* **Export vulnerability reports regularly** for compliance documentation using `pylynk vulns --output csv`.
* **Monitor vulnerability trends** across Products using the organization-level Vulnerabilities page to identify systemic issues (e.g., the same CVE appearing across multiple Products).
* **Document all VEX decisions** with clear justifications — this is essential for compliance audits and organizational knowledge transfer.