# 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 CISA's Known Exploited Vulnerabilities catalog |
| **VEX Status** | Current disposition (Affected, Not Affected, Under Investigation, Fixed)       |

### 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, and product.

***

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

CISA's KEV catalog contains vulnerabilities confirmed to be actively exploited in the wild. KEV-listed vulnerabilities should be remediated with the highest priority regardless of CVSS score.

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

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

***

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

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

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

***

## 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](https://docs.interlynk.io/administration/jira)).
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](https://docs.interlynk.io/administration/linear)).
2. Open a vulnerability detail view.
3. Click **Create Linear Issue**.
4. The issue is created with vulnerability details.

{% hint style="info" %}
Custom field values can flow into Jira tickets when custom field mappings are configured. See [Vulnerability Custom Fields](https://docs.interlynk.io/administration/vulnerability-custom-fields) 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 (CycloneDX format only). SPDX downloads include vulnerability references but not VEX data.
{% endhint %}

***

## Permission Matrix

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

For full permission details, see [Role Management](https://docs.interlynk.io/administration/role-management).

***

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