Vulnerability Correlation

Infracast automatically correlates software packages discovered by agents against known CVE databases, generating actionable vulnerability findings with severity scores and remediation guidance.

How It Works

sequenceDiagram
    participant Agent
    participant Server
    participant VulnDB
    participant NVD

    Agent->>Server: POST /report (software packages)
    Server->>VulnDB: Match packages against CVE index
    VulnDB-->>Server: Matched CVEs with CVSS scores
    Server->>Server: Create/update findings
    Server->>Server: Generate SBOM artifact
    Note over Server,NVD: Background: VulnDB syncs with NVD daily
    NVD-->>VulnDB: CVE feeds (NVD JSON v2.0 API)

CVE Database

Infracast maintains an internal vulnerability database (vulndb) that:

• Syncs with NIST NVD (National Vulnerability Database) daily via the NVD 2.0 API
• Indexes CVEs by CPE (Common Platform Enumeration) for fast package matching
• Stores CVSS v3.1 base scores, attack vectors, and CWE mappings
• Supports optional NVD API key for higher rate limits

NVD API Key

Set NVD_API_KEY in your server environment for faster CVE database syncs. Without a key, rate limiting applies but functionality is unaffected.

Package-to-CVE Matching

Matching happens in three steps:

1. Normalize Package Name and Version

apt package: openssl 3.0.2-0ubuntu1.9
→ Normalized: openssl 3.0.2
→ CPE: cpe:2.3:a:openssl:openssl:3.0.2:*:*:*:*:*:*:*

The agent's package inventory is normalized to CPE format using vendor-supplied CPE dictionaries plus community-maintained mappings.

2. Query CVE Index

The normalized CPE is matched against the CVE index. This catches:

• Exact version matches: openssl 3.0.2 matches CVE-2022-0778
• Range matches: openssl >= 3.0.0 < 3.0.7 matches multiple CVEs
• Wildcard matches: Some CVEs affect all versions of a product

3. Filter False Positives

Not every CPE match is a real vulnerability. Infracast applies:

• Platform filtering: A Windows CVE won't fire on a Linux host
• Configuration filtering: CVEs requiring specific configurations are flagged but marked as "potential"
• Severity threshold: Findings below CVSS 2.0 are suppressed by default (configurable)

Findings

Each matched CVE becomes a finding attached to the host node:

{
  "id": "fnd_abc123",
  "tenant_id": "ten_xyz",
  "node_id": "aws:us-east-1:ec2.instance:i-0abc123",
  "title": "openssl: X.400 address type confusion in X.509 GeneralName",
  "cve": "CVE-2023-0286",
  "cvss_score": 7.4,
  "cvss_vector": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:H",
  "severity": "high",
  "category": "vulnerability",
  "affected_package": "openssl",
  "affected_version": "3.0.2",
  "fixed_version": "3.0.8",
  "description": "There is a type confusion vulnerability relating to X.400...",
  "remediation": "Upgrade openssl to version 3.0.8 or later",
  "references": [
    "https://nvd.nist.gov/vuln/detail/CVE-2023-0286",
    "https://www.openssl.org/news/secadv/20230207.txt"
  ],
  "detected_at": "2026-04-16T12:00:00Z",
  "status": "open"
}

Severity Scoring

Severity	CVSS Range	Color
Critical	9.0–10.0	🔴
High	7.0–8.9	🟠
Medium	4.0–6.9	🟡
Low	0.1–3.9	🔵
Info	0.0	⚪

Severity is based on CVSS v3.1 base score. Temporal and environmental scores are displayed when available.

SBOM Generation

Every agent report generates or updates a Software Bill of Materials (SBOM) for the host.

SBOM Format

Infracast stores SBOMs internally and can export them in:

• CycloneDX 1.4 (JSON) — recommended, widely supported
• SPDX 2.3 (JSON/RDF) — NTIA minimum elements compliant

Exporting SBOMs

# Export via API
curl -H "Authorization: Bearer $TOKEN" \
  "https://api.infracast.io/api/v1/tenants/$TENANT/agents/$AGENT_ID/sbom?format=cyclonedx" \
  -o host-sbom.json

# Export for a specific host (by node ID)
curl -H "Authorization: Bearer $TOKEN" \
  "https://api.infracast.io/api/v1/tenants/$TENANT/nodes/$NODE_ID/sbom?format=spdx" \
  -o host-sbom-spdx.json

SBOM Example (CycloneDX excerpt)

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.4",
  "serialNumber": "urn:uuid:abc-123",
  "version": 1,
  "metadata": {
    "timestamp": "2026-04-16T12:00:00Z",
    "component": {
      "type": "device",
      "name": "web-server-01",
      "version": "Ubuntu 22.04.3 LTS"
    }
  },
  "components": [
    {
      "type": "library",
      "name": "openssl",
      "version": "3.0.2",
      "purl": "pkg:deb/ubuntu/openssl@3.0.2-0ubuntu1.9",
      "vulnerabilities": [
        {
          "id": "CVE-2023-0286",
          "ratings": [{"severity": "high", "score": 7.4, "method": "CVSSv31"}]
        }
      ]
    }
  ]
}

Remediation Workflow

Viewing Vulnerabilities

1. Navigate to Findings — filter by category: vulnerability
2. Or open an agent → Software tab — packages with CVEs are highlighted in red
3. Or open a host node → Vulnerabilities section

Remediation Steps

For each finding, Infracast provides:

• Affected package and version
• Fixed version (the minimum version that resolves the CVE)
• Remediation command (e.g., apt upgrade openssl)
• References (NVD, vendor advisories)

Tracking Remediation

Update finding status as you remediate:

Status	Meaning
open	Vulnerability confirmed, not remediated
acknowledged	Team is aware, working on fix
remediated	Package upgraded; finding auto-closes on next scan
risk-accepted	Won't fix — documented risk acceptance with rationale

When a package is upgraded past the fixed version, Infracast automatically resolves the finding on the next agent scan.

Compliance Integration

Vulnerability findings feed directly into compliance frameworks:

Framework	Relevant Controls
NIST SP 800-53	SI-2 (Flaw Remediation), RA-5 (Vulnerability Monitoring)
CMMC Level 2	SI.L1-3.14.1 (Identify, report, correct flaws)
FedRAMP Moderate	SI-2, RA-5, RA-5(2), RA-5(5)
PCI-DSS v4.0	6.3 (Vulnerability identification and management)
CIS AWS	Not directly applicable (agent findings apply to compute)

The compliance dashboard shows control pass/fail rates including vulnerability-related controls.

False Positive Management

Not all matched CVEs are exploitable in your environment. Infracast provides several ways to manage false positives:

Risk Acceptance

Mark a finding as risk-accepted with a rationale and expiration date:

curl -X PATCH \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  "https://api.infracast.io/api/v1/tenants/$TENANT/findings/$FINDING_ID" \
  -d '{
    "status": "risk-accepted",
    "rationale": "Mitigated by WAF; direct network access not possible",
    "accepted_by": "security-lead@example.com",
    "expires_at": "2026-10-01T00:00:00Z"
  }'

Suppression Rules

Suppress CVEs globally across all hosts in a tenant — useful for CVEs that don't apply to your configuration:

1. Navigate to Settings → Suppression Rules
2. Add rule: CVE ID + reason + expiration
3. All existing and future findings matching that CVE are suppressed

warning

Risk acceptances and suppressions are logged in the audit trail and visible to auditors. They do not permanently hide findings — they change the status with a recorded rationale.