managing-vulnerabilities

Vulnerability Management

Implement comprehensive vulnerability detection and remediation workflows across containers, source code, dependencies, and running applications. This skill covers multi-layer scanning strategies, SBOM generation (CycloneDX and SPDX), risk-based prioritization using CVSS/EPSS/KEV, and CI/CD security gate patterns.

When to Use This Skill

Invoke this skill when:

• Building security scanning into CI/CD pipelines
• Generating Software Bills of Materials (SBOMs) for compliance
• Prioritizing vulnerability remediation using risk-based approaches
• Implementing security gates (fail builds on critical vulnerabilities)
• Scanning container images before deployment
• Detecting secrets, misconfigurations, or code vulnerabilities
• Establishing DevSecOps practices and automation
• Meeting regulatory requirements (SBOM mandates, Executive Order 14028)

Multi-Layer Scanning Strategy

Vulnerability management requires scanning at multiple layers. Each layer detects different types of security issues.

Layer Overview

Container Image Scanning

• Detects vulnerabilities in OS packages, language dependencies, and binaries
• Tools: Trivy (comprehensive), Grype (accuracy-focused), Snyk Container (commercial)
• When: Every container build, base image selection, registry admission control

SAST (Static Application Security Testing)

• Analyzes source code for security flaws before runtime
• Tools: Semgrep (fast, semantic), Snyk Code (developer-first), SonarQube (enterprise)
• When: Every commit, PR checks, main branch protection

DAST (Dynamic Application Security Testing)

• Tests running applications for vulnerabilities (black-box testing)
• Tools: OWASP ZAP (open-source), StackHawk (CI/CD native), Burp Suite (manual + automated)
• When: Staging environment testing, API validation, authentication testing

SCA (Software Composition Analysis)

• Analyzes third-party dependencies for known vulnerabilities
• Tools: Dependabot (GitHub native), Renovate (advanced), Snyk Open Source (commercial)
• When: Every build, dependency updates, license audits

Secret Scanning

• Prevents secrets from being committed to source code
• Tools: Gitleaks (fast, configurable), TruffleHog (entropy detection), GitGuardian (commercial)
• When: Pre-commit hooks, repository scanning, CI/CD artifact checks

Quick Tool Selection

Container Image → Trivy (default choice) OR Grype (accuracy focus)
Source Code → Semgrep (open-source) OR Snyk Code (commercial)
Running Application → OWASP ZAP (open-source) OR StackHawk (CI/CD native)
Dependencies → Dependabot (GitHub) OR Renovate (advanced automation)
Secrets → Gitleaks (open-source) OR GitGuardian (commercial)

For detailed tool selection guidance, see references/tool-selection.md.

SBOM Generation

Software Bills of Materials (SBOMs) provide a complete inventory of software components and dependencies. Required for compliance and security transparency.

CycloneDX vs. SPDX

CycloneDX (Recommended for DevSecOps)

• Security-focused, OWASP-maintained
• Native vulnerability references
• Fast, lightweight (JSON/XML/ProtoBuf)
• Best for: DevSecOps pipelines, vulnerability tracking

SPDX (Recommended for Legal/Compliance)

• License compliance focus, ISO standard (ISO/IEC 5962:2021)
• Comprehensive legal metadata
• Government/defense preferred format
• Best for: Legal teams, compliance audits, federal requirements

Generating SBOMs

With Trivy (CycloneDX or SPDX):

# CycloneDX format (recommended for security)
trivy image --format cyclonedx --output sbom.json myapp:latest

# SPDX format (for compliance)
trivy image --format spdx-json --output sbom-spdx.json myapp:latest

# Scan SBOM (faster than re-scanning image)
trivy sbom sbom.json --severity HIGH,CRITICAL

With Syft (high accuracy):

# Generate CycloneDX
syft myapp:latest -o cyclonedx-json=sbom.json

# Generate SPDX
syft myapp:latest -o spdx-json=sbom-spdx.json

# Pipe to Grype for scanning
syft myapp:latest -o json | grype

For comprehensive SBOM patterns and storage strategies, see references/sbom-guide.md.

Vulnerability Prioritization

Not all vulnerabilities require immediate action. Prioritize based on actual risk using CVSS, EPSS, and KEV.

Modern Risk-Based Prioritization

Step 1: Gather Metrics

| Metric | Source | Purpose | |--------|--------|---------| | CVSS Base Score | NVD, vendor advisories | Vulnerability severity (0-10) | | EPSS Score | FIRST.org API | Exploitation probability (0-1) | | KEV Status | CISA KEV Catalog | Actively exploited CVEs | | Asset Criticality | Internal CMDB | Business impact if compromised | | Exposure | Network topology | Internet-facing vs. internal |

Step 2: Calculate Priority

Priority Score = (CVSS × 0.3) + (EPSS × 100 × 0.3) + (KEV × 50) + (Asset × 0.2) + (Exposure × 0.2)

KEV: 1 if in KEV catalog, 0 otherwise
Asset: 1 (Critical), 0.7 (High), 0.4 (Medium), 0.1 (Low)
Exposure: 1 (Internet-facing), 0.5 (Internal), 0.1 (Isolated)

Step 3: Apply SLA Tiers

| Priority | Criteria | SLA | Action | |----------|----------|-----|--------| | P0 - Critical | KEV + Internet-facing + Critical asset | 24 hours | Emergency patch immediately | | P1 - High | CVSS ≥ 9.0 OR (CVSS ≥ 7.0 AND EPSS ≥ 0.1) | 7 days | Prioritize in sprint, patch ASAP | | P2 - Medium | CVSS 7.0-8.9 OR EPSS ≥ 0.05 | 30 days | Normal sprint planning | | P3 - Low | CVSS 4.0-6.9, EPSS < 0.05 | 90 days | Backlog, maintenance windows | | P4 - Info | CVSS < 4.0 | No SLA | Track, address opportunistically |

Example: Log4Shell (CVE-2021-44228)

CVSS: 10.0
EPSS: 0.975 (97.5% exploitation probability)
KEV: Yes (CISA catalog)
Asset: Critical (payment API)
Exposure: Internet-facing

Priority Score = (10 × 0.3) + (97.5 × 0.3) + 50 + (1 × 0.2) + (1 × 0.2) = 82.65
Result: P0 - Critical (24-hour SLA)

For complete prioritization framework and automation scripts, see references/prioritization-framework.md.

CI/CD Integration Patterns

Multi-Stage Security Pipeline

Implement progressive security gates across pipeline stages:

Stage 1: Pre-Commit (Developer Workstation)

Tools: Secret scanning (Gitleaks), SAST (Semgrep)
Threshold: Block high-confidence secrets, critical SAST findings
Speed: < 10 seconds

Stage 2: Pull Request (CI Pipeline)

Tools: SAST, SCA, Secret scanning
Threshold: No Critical/High vulnerabilities, no secrets
Speed: < 5 minutes
Action: Block PR merge until fixed

Stage 3: Build (CI Pipeline)

Tools: Container scanning (Trivy), SBOM generation
Threshold: No Critical vulnerabilities in production dependencies
Artifacts: SBOM stored, scan results uploaded
Speed: < 2 minutes
Action: Fail build on Critical findings

Stage 4: Pre-Deployment (Staging)

Tools: DAST, Integration tests
Threshold: No Critical/High DAST findings
Speed: 10-30 minutes
Action: Gate deployment to production

Stage 5: Production (Runtime)

Tools: Continuous scanning, runtime monitoring
Threshold: Alert on new CVEs in deployed images
Action: Alert security team, plan patching

Example: GitHub Actions Multi-Stage Scan

name: Security Scan Pipeline

on: [push, pull_request]

jobs:
  secrets:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: trufflesecurity/trufflehog@main
        with:
          path: ./
          extra_args: --only-verified

  sast:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: semgrep/semgrep-action@v1
        with:
          config: p/security-audit

  container:
    runs-on: ubuntu-latest
    needs: [secrets, sast]
    steps:
      - uses: actions/checkout@v4
      - run: docker build -t myapp:${{ github.sha }} .

      - uses: aquasecurity/trivy-action@master
        with:
          image-ref: myapp:${{ github.sha }}
          format: sarif
          output: trivy-results.sarif
          sev