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