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

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.

---

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.

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.

---

VEX Status (Vulnerability Disposition)

The 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

All "Not Affected" dispositions must include a justification. This is required for VEX compliance and provides audit evidence for compliance frameworks.

---

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

# 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

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

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

2. Open a vulnerability detail view.

3. Click Create Linear Issue.

4. The issue is created with vulnerability details.

Custom field values can flow into Jira tickets when custom field mappings are configured. See Vulnerability Custom Fields for details.

---

Downloading Vulnerability Data

Vulnerability data can be included in SBOM downloads:

# 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

Vulnerability data in downloaded SBOMs includes VEX status and justifications (CycloneDX format only). SPDX downloads include vulnerability references but not VEX data.

---

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.

---

Security Warnings

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.

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.

Custom CVSS adjustments override the original severity. Misconfigured adjustments can suppress critical vulnerabilities. Review all custom scoring changes periodically.

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.

---

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.