/managing-vulnerabilities

name: managing-vulnerabilities
description: Implementing multi-layer security scanning (container, SAST, DAST, SCA, secrets), SBOM generation, and risk-based vulnerability prioritization in CI/CD pipelines. Use when building DevSecOps workflows, ensuring compliance, or establishing security gates for container deployments.

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