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

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

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
          severity: HIGH,CRITICAL
          exit-code: 1

      - name: Generate SBOM
        run: |
          trivy image --format cyclonedx \
            --output sbom.json myapp:${{ github.sha }}

      - uses: actions/upload-artifact@v3
        with:
          name: sbom
          path: sbom.json

For complete CI/CD patterns (GitLab CI, Jenkins, Azure Pipelines), see references/ci-cd-patterns.md.

Container Scanning with Trivy

Trivy is the recommended default for container scanning: comprehensive, fast, and CI/CD native.

Basic Usage

# Scan container image
trivy image alpine:latest

# Scan with severity filter
trivy image --severity HIGH,CRITICAL alpine:latest

# Fail on findings (CI/CD)
trivy image --exit-code 1 --severity HIGH,CRITICAL myapp:latest

# Generate SBOM
trivy image --format cyclonedx --output sbom.json alpine:latest

# Scan filesystem
trivy fs /path/to/project

# Scan Kubernetes manifests
trivy config deployment.yaml

Configuration (.trivy.yaml)

severity: HIGH,CRITICAL
exit-code: 1
ignore-unfixed: true  # Only fail on fixable vulnerabilities
vuln-type: os,library
skip-dirs:
  - node_modules
  - vendor
ignorefile: .trivyignore

Ignoring False Positives (.trivyignore)

# False positive
CVE-2023-12345

# Accepted risk with justification
CVE-2023-67890  # Risk accepted: Not exploitable in our use case

# Development dependency (not in production)
CVE-2023-11111  # Dev dependency only

GitHub Actions Integration

- name: Trivy Scan
  uses: aquasecurity/trivy-action@master
  with:
    image-ref: myapp:${{ github.sha }}
    format: sarif
    output: trivy-results.sarif
    severity: HIGH,CRITICAL
    exit-code: 1

- name: Upload to GitHub Security
  uses: github/codeql-action/upload-sarif@v2
  if: always()
  with:
    sarif_file: trivy-results.sarif

Alternative: Grype for Accuracy

Grype focuses on minimal false positives and works with Syft for SBOM generation.

Important: Use Grype v0.104.1 or later (credential disclosure CVE-2025-65965 patched in earlier versions).

Basic Usage

# Scan container image
grype alpine:latest

# Scan with severity threshold
grype alpine:latest --fail-on high

# Scan SBOM (faster)
grype sbom:./sbom.json

# Syft + Grype workflow
syft alpine:latest -o json | grype --fail-on critical

When to Use Grype

• Projects sensitive to false positives
• SBOM-first workflows (generate with Syft, scan with Grype)
• Need second opinion validation
• Anchore ecosystem users

For complete tool comparisons and selection criteria, see references/tool-selection.md.

Security Gates and Thresholds

Progressive Threshold Strategy

Balance security and development velocity with progressive gates. Configure different thresholds for PR checks (fast, HIGH+CRITICAL), builds (comprehensive), and deployments (strict, CRITICAL only).

Policy-as-Code

Use OPA (Open Policy Agent) for automated policy enforcement. Create policies to deny Critical vulnerabilities, enforce KEV catalog checks, and implement environment-specific rules.

For complete policy patterns, baseline detection, and OPA examples, see references/policy-as-code.md.

Remediation Workflows

Automated Remediation

Set up automated workflows to scan daily, extract fixable vulnerabilities, update dependencies, and create remediation pull requests automatically.

SLA Tracking

Track vulnerability remediation against SLA targets (P0: 24 hours, P1: 7 days, P2: 30 days, P3: 90 days). Monitor overdue vulnerabilities and escalate as needed.

False Positive Management

Maintain suppression files (.trivyignore) with documented justifications, review dates, and approval tracking. Implement workflows for false positive triage and approval.

For complete remediation workflows, SLA trackers, and automation scripts, see references/remediation-workflows.md.

Integration with Related Skills

building-ci-pipelines

• Add security stages to pipeline definitions
• Configure artifacts for SBOM storage
• Implement quality gates with vulnerability thresholds

secret-management

• Integrate secret scanning (Gitleaks, TruffleHog)
• Automate secret rotation on detection
• Use pre-commit hooks for prevention

infrastructure-as-code

• Scan Terraform and Kubernetes manifests with Trivy config
• Detect misconfigurations before deployment
• Enforce policy-as-code with OPA

security-hardening

• Apply remediation guidance from scan results
• Select secure base images
• Implement security best practices

compliance-frameworks

• Generate SBOMs for SOC2, ISO 27001 audits
• Track vulnerability metrics for compliance reporting
• Provide evidence for security controls

Quick Reference

Essential Commands

# Trivy: Scan image with severity filter
trivy image --severity HIGH,CRITICAL myapp:latest

# Trivy: Generate SBOM
trivy image --format cyclonedx --output sbom.json myapp:latest

# Trivy: Scan SBOM
trivy sbom sbom.json

# Grype: Scan image
grype myapp:latest --fail-on high

# Syft + Grype: SBOM workflow
syft myapp:latest -o json | grype

# Gitleaks: Scan for secrets
gitleaks detect --source . --verbose

Common Patterns

# CI/CD: Fail build on Critical
trivy image --exit-code 1 --severity CRITICAL myapp:latest

# Ignore unfixed vulnerabilities
trivy image --ignore-unfixed --severity HIGH,CRITICAL myapp:latest

# Scan only OS packages
trivy image --vuln-type os myapp:latest

# Skip specific directories
trivy fs --skip-dirs node_modules,vendor .

Progressive Disclosure

This skill provides foundational vulnerability management patterns. For deeper topics:

• Tool Selection: references/tool-selection.md - Complete decision frameworks
• SBOM Patterns: references/sbom-guide.md - Generation, storage, consumption
• Prioritization: references/prioritization-framework.md - CVSS/EPSS/KEV automation
• CI/CD Integration: references/ci-cd-patterns.md - GitLab CI, Jenkins, Azure Pipelines
• Remediation: references/remediation-workflows.md - SLA tracking, false positives
• Policy-as-Code: references/policy-as-code.md - OPA examples, security gates

Working Examples:

• examples/trivy/ - Trivy scanning patterns
• examples/grype/ - Grype + Syft workflows
• examples/ci-cd/ - Complete pipeline configurations
• examples/sbom/ - SBOM generation and management
• examples/prioritization/ - EPSS and KEV integration scripts

Automation Scripts:

• scripts/vulnerability-report.sh - Generate executive reports
• scripts/sla-tracker.sh - Track remediation SLAs
• scripts/false-positive-manager.sh - Manage suppression rules

CI/CD Security Scanning Patterns

Complete CI/CD integration patterns for GitHub Actions, GitLab CI, Jenkins, and Azure Pipelines.

Table of Contents

1. GitHub Actions 2. GitLab CI 3. Jenkins 4. Azure Pipelines

---

GitHub Actions

Multi-Stage Security Pipeline

name: Security Scan Pipeline

on:
  pull_request:
  push:
    branches: [main]

jobs:
  # Stage 1: Fast checks (secrets, SAST)
  secrets:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0

      - name: Gitleaks Scan
        uses: gitleaks/gitleaks-action@v2
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

  sast:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Semgrep Scan
        uses: semgrep/semgrep-action@v1
        with:
          config: >-
            p/security-audit
            p/secrets
            p/owasp-top-ten

  # Stage 2: Dependency scanning
  dependencies:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Dependency Review
        uses: actions/dependency-review-action@v3
        with:
          fail-on-severity: high

  # Stage 3: Container scanning (after fast checks)
  container:
    runs-on: ubuntu-latest
    needs: [secrets, sast]
    steps:
      - uses: actions/checkout@v4

      - name: Build image
        run: docker build -t myapp:${{ github.sha }} .

      - name: Run Trivy scan
        uses: aquasecurity/trivy-action@master
        with:
          image-ref: myapp:${{ github.sha }}
          format: sarif
          output: trivy-results.sarif
          severity: HIGH,CRITICAL
          exit-code: 1

      - name: Upload Trivy results
        uses: github/codeql-action/upload-sarif@v2
        if: always()
        with:
          sarif_file: trivy-results.sarif

      - name: Generate SBOM
        run: |
          trivy image --format cyclonedx \
            --output sbom.json \
            myapp:${{ github.sha }}

      - name: Upload SBOM
        uses: actions/upload-artifact@v3
        with:
          name: sbom
          path: sbom.json

  # Stage 4: DAST (only on main branch)
  dast:
    runs-on: ubuntu-latest
    if: github.ref == 'refs/heads/main'
    needs: container
    steps:
      - uses: actions/checkout@v4

      - name: OWASP ZAP Baseline Scan
        uses: zaproxy/action-baseline@v0.7.0
        with:
          target: https://staging.example.com
          fail_action: true

GitLab CI

stages:
  - security-fast
  - security-scan
  - security-test

variables:
  IMAGE_TAG: $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA

# Fast checks
gitleaks:
  stage: security-fast
  image: zricethezav/gitleaks:latest
  script:
    - gitleaks detect --source . --verbose --exit-code 1
  allow_failure: false

semgrep:
  stage: security-fast
  image: returntocorp/semgrep
  script:
    - semgrep ci --config=p/security-audit
  allow_failure: false

# Container scanning
trivy-scan:
  stage: security-scan
  image: aquasec/trivy:latest
  script:
    - trivy image --severity HIGH,CRITICAL --exit-code 1 $IMAGE_TAG
  artifacts:
    reports:
      container_scanning: gl-container-scanning-report.json

# SBOM generation
sbom-generate:
  stage: security-scan
  image: aquasec/trivy:latest
  script:
    - trivy image --format cyclonedx --output sbom.json $IMAGE_TAG
  artifacts:
    paths:
      - sbom.json
    expire_in: 90 days

# DAST
zap-scan:
  stage: security-test
  image: owasp/zap2docker-stable
  script:
    - zap-baseline.py -t https://staging.example.com -r zap-report.html
  artifacts:
    paths:
      - zap-report.html
    when: always
  only:
    - main

Jenkins

pipeline {
    agent any

    environment {
        IMAGE_NAME = "myapp"
        IMAGE_TAG = "${env.GIT_COMMIT}"
    }

    stages {
        stage('Secret Scanning') {
            steps {
                sh 'gitleaks detect --source . --verbose --exit-code 1'
            }
        }

        stage('SAST') {
            steps {
                sh 'semgrep ci --config=p/security-audit'
            }
        }

        stage('Build Image') {
            steps {
                sh "docker build -t ${IMAGE_NAME}:${IMAGE_TAG} ."
            }
        }

        stage('Container Scan') {
            steps {
                sh """
                    trivy image --severity HIGH,CRITICAL \
                      --exit-code 1 \
                      --format json \
                      --output trivy-results.json \
                      ${IMAGE_NAME}:${IMAGE_TAG}
                """
            }
        }

        stage('Generate SBOM') {
            steps {
                sh """
                    trivy image --format cyclonedx \
                      --output sbom.json \
                      ${IMAGE_NAME}:${IMAGE_TAG}
                """
                archiveArtifacts artifacts: 'sbom.json'
            }
        }

        stage('DAST') {
            when {
                branch 'main'
            }
            steps {
                sh '''
                    docker run -v $(pwd):/zap/wrk/:rw \
                      owasp/zap2docker-stable \
                      zap-baseline.py -t https://staging.example.com \
                      -r zap-report.html
                '''
            }
        }
    }

    post {
        always {
            publishHTML([
                reportDir: '.',
                reportFiles: 'zap-report.html',
                reportName: 'ZAP Security Report'
            ])
        }
        failure {
            emailext(
                subject: "Security Scan Failed: ${env.JOB_NAME}",
                body: "Build ${env.BUILD_NUMBER} failed security scans.",
                to: "security-team@example.com"
            )
        }
    }
}

Azure Pipelines

trigger:
  branches:
    include:
      - main
      - develop

pool:
  vmImage: 'ubuntu-latest'

variables:
  imageName: 'myapp'
  imageTag: $(Build.BuildId)

stages:
  - stage: SecurityFast
    displayName: 'Fast Security Checks'
    jobs:
      - job: Secrets
        steps:
          - task: Bash@3
            displayName: 'Gitleaks Scan'
            inputs:
              targetType: 'inline'
              script: |
                wget https://github.com/gitleaks/gitleaks/releases/download/v8.18.0/gitleaks_8.18.0_linux_x64.tar.gz
                tar -xzf gitleaks_8.18.0_linux_x64.tar.gz
                ./gitleaks detect --source . --verbose --exit-code 1

      - job: SAST
        steps:
          - task: Bash@3
            displayName: 'Semgrep Scan'
            inputs:
              targetType: 'inline'
              script: |
                pip install semgrep
                semgrep ci --config=p/security-audit

  - stage: ContainerScan
    displayName: 'Container Security Scan'
    dependsOn: SecurityFast
    jobs:
      - job: BuildAndScan
        steps:
          - task: Docker@2
            displayName: 'Build image'
            inputs:
              command: 'build'
              repository: $(imageName)
              tags: $(imageTag)

          - task: Bash@3
            displayName: 'Trivy Scan'
            inputs:
              targetType: 'inline'
              script: |
                wget https://github.com/aquasecurity/trivy/releases/download/v0.48.0/trivy_0.48.0_Linux-64bit.tar.gz
                tar -xzf trivy_0.48.0_Linux-64bit.tar.gz
                ./trivy image --severity HIGH,CRITICAL --exit-code 1 $(imageName):$(imageTag)

          - task: Bash@3
            displayName: 'Generate SBOM'
            inputs:
              targetType: 'inline'
              script: |
                ./trivy image --format cyclonedx --output $(Build.ArtifactStagingDirectory)/sbom.json $(imageName):$(imageTag)

          - task: PublishBuildArtifacts@1
            inputs:
              pathToPublish: '$(Build.ArtifactStagingDirectory)/sbom.json'
              artifactName: 'sbom'

See complete examples in examples/ci-cd/ directory.

Policy-as-Code for Vulnerability Management

Implement security policies using OPA (Open Policy Agent) and automated enforcement.

Table of Contents

1. OPA Vulnerability Policies 2. Using OPA with Trivy 3. Advanced Policies 4. Policy Testing

---

OPA Vulnerability Policies

Basic Vulnerability Policy

package vulnerability

# Deny if any Critical vulnerabilities found
deny[msg] {
    input.Vulnerabilities[_].Severity == "CRITICAL"
    msg := "Critical vulnerabilities detected - build failed"
}

# Deny if High vulnerabilities in production dependencies
deny[msg] {
    vuln := input.Vulnerabilities[_]
    vuln.Severity == "HIGH"
    not contains(vuln.PkgPath, "node_modules/dev")
    msg := sprintf("High vulnerability in production: %v (%v)", [vuln.PkgName, vuln.VulnerabilityID])
}

# Warn if unfixed vulnerabilities
warn[msg] {
    vuln := input.Vulnerabilities[_]
    vuln.FixedVersion == ""
    msg := sprintf("Unfixed vulnerability: %v in %v", [vuln.VulnerabilityID, vuln.PkgName])
}

KEV-Aware Policy

package vulnerability

import future.keywords.in

# KEV catalog data (load separately or embed)
kev_catalog := {
    "CVE-2021-44228",
    "CVE-2021-45046",
    # ... more KEV CVEs
}

# Deny if vulnerability is in KEV catalog
deny[msg] {
    vuln := input.Vulnerabilities[_]
    vuln.VulnerabilityID in kev_catalog
    msg := sprintf("KEV vulnerability detected: %v - immediate remediation required", [vuln.VulnerabilityID])
}

# Helper function to check KEV
is_kev(cve_id) {
    cve_id in kev_catalog
}

CVSS-Based Policy

package vulnerability

# Deny based on CVSS score and package location
deny[msg] {
    vuln := input.Vulnerabilities[_]
    cvss_score := vuln.CVSS.nvd.V3Score
    cvss_score >= 7.0
    is_production_dependency(vuln.PkgPath)
    msg := sprintf("CVSS %v vulnerability in production: %v", [cvss_score, vuln.VulnerabilityID])
}

# Helper: Check if production dependency
is_production_dependency(path) {
    not contains(path, "test")
    not contains(path, "dev")
    not contains(path, "node_modules/@types")
}

Using OPA with Trivy

Scan and Evaluate Policy

#!/bin/bash
# Scan with Trivy and evaluate OPA policy

IMAGE="myapp:latest"
POLICY_DIR="policies"

# Scan image
trivy image --format json --output scan.json "$IMAGE"

# Evaluate policy
opa eval --data "$POLICY_DIR" --input scan.json \
  'data.vulnerability.deny' --format pretty

# Exit code based on policy
if opa eval --data "$POLICY_DIR" --input scan.json 'data.vulnerability.deny' | grep -q "true"; then
  echo "Policy violations found - build failed"
  exit 1
fi

CI/CD Integration

# .github/workflows/policy-check.yml
name: Policy Enforcement

on: [push, pull_request]

jobs:
  security-policy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Build image
        run: docker build -t myapp:${{ github.sha }} .

      - name: Scan with Trivy
        run: trivy image --format json --output scan.json myapp:${{ github.sha }}

      - name: Install OPA
        run: |
          curl -L -o opa https://openpolicyagent.org/downloads/latest/opa_linux_amd64
          chmod +x opa

      - name: Evaluate security policy
        run: |
          ./opa eval --data policies/ --input scan.json \
            'data.vulnerability.deny' --format pretty

      - name: Enforce policy
        run: |
          VIOLATIONS=$(./opa eval --data policies/ --input scan.json 'data.vulnerability.deny' --format values)
          if [ -n "$VIOLATIONS" ]; then
            echo "Policy violations:"
            echo "$VIOLATIONS"
            exit 1
          fi

Advanced Policies

Multi-Tier Policy

package vulnerability

# P0: Critical + KEV
p0_violations[msg] {
    vuln := input.Vulnerabilities[_]
    vuln.Severity == "CRITICAL"
    is_kev(vuln.VulnerabilityID)
    msg := sprintf("P0: %v (KEV + Critical)", [vuln.VulnerabilityID])
}

# P1: High CVSS or High + EPSS
p1_violations[msg] {
    vuln := input.Vulnerabilities[_]
    cvss := vuln.CVSS.nvd.V3Score
    cvss >= 9.0
    msg := sprintf("P1: %v (CVSS %v)", [vuln.VulnerabilityID, cvss])
}

# Aggregate violations
violations := array.concat(p0_violations, p1_violations)

# Deny if any P0 or P1
deny[msg] {
    count(violations) > 0
    msg := sprintf("Found %v high-priority violations", [count(violations)])
}

Environment-Specific Policies

package vulnerability

# Get environment from metadata
environment := input.Metadata.Environment

# Production: Zero tolerance
deny[msg] {
    environment == "production"
    input.Vulnerabilities[_].Severity == "CRITICAL"
    msg := "Production: No Critical vulnerabilities allowed"
}

# Staging: Warn only
warn[msg] {
    environment == "staging"
    input.Vulnerabilities[_].Severity == "CRITICAL"
    msg := "Staging: Critical vulnerabilities present (warning only)"
}

# Development: Allow but track
info[msg] {
    environment == "development"
    count(input.Vulnerabilities) > 0
    msg := sprintf("Development: %v vulnerabilities tracked", [count(input.Vulnerabilities)])
}

Policy Testing

OPA Policy Tests

package vulnerability_test

import data.vulnerability

# Test: Deny Critical vulnerabilities
test_deny_critical {
    input := {"Vulnerabilities": [{"Severity": "CRITICAL", "VulnerabilityID": "CVE-2023-12345"}]}
    count(vulnerability.deny) > 0
}

# Test: Allow Low vulnerabilities
test_allow_low {
    input := {"Vulnerabilities": [{"Severity": "LOW", "VulnerabilityID": "CVE-2023-99999"}]}
    count(vulnerability.deny) == 0
}

# Test: KEV detection
test_kev_detection {
    input := {"Vulnerabilities": [{"VulnerabilityID": "CVE-2021-44228", "Severity": "CRITICAL"}]}
    count(vulnerability.deny) > 0
}

Run tests:

opa test policies/ -v

See complete policies in examples/opa/ directory.

Vulnerability Prioritization Framework

Risk-based vulnerability prioritization using CVSS, EPSS, KEV, and business context.

Table of Contents

1. Overview 2. CVSS Scoring 3. EPSS Integration 4. KEV Catalog 5. Risk-Based Formula 6. SLA Tiers 7. Automation Scripts 8. Examples

---

Overview

The Problem with CVSS Alone

CVSS Base Score limitations:

• Treats all Critical CVEs equally (not all are exploited)
• Static score, doesn't reflect threat landscape
• No consideration of actual risk to your environment
• Results in "patch everything" approach (unsustainable)

Modern Risk-Based Approach

Combine multiple data sources:

---

CVSS Scoring

CVSS v3.1 Overview

Base Score Components:

Attack Vector (AV):

• Network (N): Remotely exploitable
• Adjacent (A): Local network required
• Local (L): Local access required
• Physical (P): Physical access required

Attack Complexity (AC):

• Low (L): No special conditions
• High (H): Specific conditions required

Privileges Required (PR):

• None (N): Unauthenticated
• Low (L): Basic user privileges
• High (H): Administrator privileges

User Interaction (UI):

• None (N): No interaction needed
• Required (R): User action required

Impact (CIA):

• High (H): Total loss
• Low (L): Limited loss
• None (N): No impact

Severity Ranges

Fetching CVSS Scores

# From NVD API
curl "https://services.nvd.nist.gov/rest/json/cves/2.0?cveId=CVE-2021-44228" | \
  jq '.vulnerabilities[0].cve.metrics.cvssMetricV31[0].cvssData.baseScore'

# From Trivy scan
trivy image myapp:latest --format json | \
  jq '.Results[].Vulnerabilities[] | {cve: .VulnerabilityID, cvss: .CVSS.nvd.V3Score}'

---

EPSS Integration

What is EPSS?

Exploit Prediction Scoring System (EPSS) predicts the probability a vulnerability will be exploited within 30 days.

Based On:

• Exploit availability (PoC, Metasploit modules)
• Public discussions and mentions
• Vulnerability characteristics
• Historical exploitation patterns

EPSS Score Interpretation

Using EPSS API

Fetch EPSS Score:

# Single CVE
curl "https://api.first.org/data/v1/epss?cve=CVE-2021-44228" | jq '.'

# Response:
{
  "status": "OK",
  "data": [{
    "cve": "CVE-2021-44228",
    "epss": "0.97505",
    "percentile": "0.99999"
  }]
}

# Multiple CVEs
curl "https://api.first.org/data/v1/epss?cve=CVE-2021-44228,CVE-2023-12345"

# All CVEs (large download)
curl "https://api.first.org/data/v1/epss" --output epss-all.csv

Python Integration:

import requests

def get_epss_score(cve_id):
    """Fetch EPSS score for CVE"""
    url = f"https://api.first.org/data/v1/epss?cve={cve_id}"
    response = requests.get(url)
    data = response.json()

    if data['status'] == 'OK' and data['data']:
        return float(data['data'][0]['epss'])
    return 0.0

# Example
score = get_epss_score("CVE-2021-44228")
print(f"EPSS Score: {score:.4f} ({score*100:.2f}%)")
# Output: EPSS Score: 0.9751 (97.51%)

---

KEV Catalog

CISA Known Exploited Vulnerabilities

CVEs actively exploited in the wild. If in KEV → Immediate action required.

KEV Catalog: https://www.cisa.gov/known-exploited-vulnerabilities-catalog

Using KEV Catalog

Download KEV Data:

# Download JSON
curl -o kev.json https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json

# Query specific CVE
jq '.vulnerabilities[] | select(.cveID == "CVE-2021-44228")' kev.json

Check if CVE is in KEV:

import requests

def is_in_kev(cve_id):
    """Check if CVE is in CISA KEV catalog"""
    url = "https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json"
    response = requests.get(url)
    kev_data = response.json()

    for vuln in kev_data['vulnerabilities']:
        if vuln['cveID'] == cve_id:
            return True, vuln.get('dateAdded'), vuln.get('dueDate')
    return False, None, None

# Example
in_kev, added, due = is_in_kev("CVE-2021-44228")
if in_kev:
    print(f"P0 CRITICAL: In KEV catalog (added {added}, due {due})")

KEV Response Fields:

{
  "cveID": "CVE-2021-44228",
  "vendorProject": "Apache",
  "product": "Log4j",
  "vulnerabilityName": "Log4j2 Remote Code Execution",
  "dateAdded": "2021-12-10",
  "shortDescription": "Apache Log4j2 ...",
  "requiredAction": "Apply updates per vendor instructions.",
  "dueDate": "2021-12-24"
}

---

Risk-Based Formula

Weighted Priority Score

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

Where:
- CVSS: Base score (0-10)
- EPSS: Probability (0-1), scaled to 0-100
- KEV: 1 if in KEV catalog, 0 otherwise (multiplied by 50)
- Asset: 1.0 (Critical), 0.7 (High), 0.4 (Medium), 0.1 (Low)
- Exposure: 1.0 (Internet-facing), 0.5 (Internal), 0.1 (Isolated)

Maximum Score: 10×0.3 + 100×0.3 + 50 + 1×0.2 + 1×0.2 = 83.4

Asset Criticality Matrix

Exposure Matrix

---

SLA Tiers

Priority Definitions

SLA Escalation

Day 1-7:   Normal remediation
Day 8-14:  Manager notification
Day 15-21: Director escalation
Day 22+:   Executive escalation, risk acceptance required

---

Automation Scripts

Python Priority Calculator

import requests

class VulnerabilityPrioritizer:
    def __init__(self):
        self.kev_cache = None

    def get_epss_score(self, cve_id):
        """Fetch EPSS score from API"""
        url = f"https://api.first.org/data/v1/epss?cve={cve_id}"
        response = requests.get(url)
        data = response.json()
        if data['status'] == 'OK' and data['data']:
            return float(data['data'][0]['epss'])
        return 0.0

    def is_in_kev(self, cve_id):
        """Check KEV catalog"""
        if not self.kev_cache:
            url = "https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json"
            response = requests.get(url)
            self.kev_cache = response.json()

        for vuln in self.kev_cache['vulnerabilities']:
            if vuln['cveID'] == cve_id:
                return True
        return False

    def calculate_priority(self, cve_id, cvss_score, asset_criticality, exposure):
        """
        Calculate priority score

        Args:
            cve_id: CVE identifier
            cvss_score: CVSS base score (0-10)
            asset_criticality: 1.0 (Critical), 0.7 (High), 0.4 (Medium), 0.1 (Low)
            exposure: 1.0 (Internet), 0.5 (Internal), 0.1 (Isolated)
        """
        epss_score = self.get_epss_score(cve_id)
        kev_status = 1 if self.is_in_kev(cve_id) else 0

        priority_score = (
            (cvss_score * 0.3) +
            (epss_score * 100 * 0.3) +
            (kev_status * 50) +
            (asset_criticality * 0.2) +
            (exposure * 0.2)
        )

        # Determine priority tier
        if kev_status and exposure >= 0.5 and asset_criticality >= 0.7:
            tier = "P0"
            sla_hours = 24
        elif cvss_score >= 9.0 or (cvss_score >= 7.0 and epss_score >= 0.1):
            tier = "P1"
            sla_hours = 7 * 24
        elif cvss_score >= 7.0 or epss_score >= 0.05:
            tier = "P2"
            sla_hours = 30 * 24
        elif cvss_score >= 4.0:
            tier = "P3"
            sla_hours = 90 * 24
        else:
            tier = "P4"
            sla_hours = None

        return {
            'cve_id': cve_id,
            'cvss': cvss_score,
            'epss': epss_score,
            'kev': kev_status,
            'asset': asset_criticality,
            'exposure': exposure,
            'priority_score': round(priority_score, 2),
            'tier': tier,
            'sla_hours': sla_hours
        }

# Usage
prioritizer = VulnerabilityPrioritizer()

result = prioritizer.calculate_priority(
    cve_id="CVE-2021-44228",
    cvss_score=10.0,
    asset_criticality=1.0,  # Critical
    exposure=1.0  # Internet-facing
)

print(f"{result['tier']}: {result['cve_id']}")
print(f"  Priority Score: {result['priority_score']}")
print(f"  SLA: {result['sla_hours']} hours")
print(f"  CVSS: {result['cvss']}, EPSS: {result['epss']:.4f}, KEV: {bool(result['kev'])}")

---

Examples

Example 1: Log4Shell (Critical)

CVE: CVE-2021-44228 (Log4Shell)
CVSS: 10.0
EPSS: 0.97505 (97.5%)
KEV: Yes (CISA catalog)
Asset: Critical (payment API)
Exposure: Internet-facing

Calculation:
Priority Score = (10 × 0.3) + (97.5 × 0.3) + (1 × 50) + (1 × 0.2) + (1 × 0.2)
               = 3 + 29.25 + 50 + 0.2 + 0.2
               = 82.65

Result: P0 - Critical
SLA: 24 hours
Action: Emergency patch immediately, all hands on deck

---

Example 2: High CVSS, Low EPSS

CVE: CVE-2023-99999 (Hypothetical)
CVSS: 9.0 (High)
EPSS: 0.001 (0.1%)
KEV: No
Asset: Medium (internal dashboard)
Exposure: Internal only

Calculation:
Priority Score = (9 × 0.3) + (0.1 × 0.3) + (0 × 50) + (0.4 × 0.2) + (0.5 × 0.2)
               = 2.7 + 0.03 + 0 + 0.08 + 0.1
               = 2.91

Result: P3 - Low
SLA: 90 days
Action: Backlog, address in maintenance window
Reasoning: High CVSS but very low exploitation probability, internal only, medium asset

---

Example 3: Medium CVSS, High EPSS

CVE: CVE-2023-88888 (Hypothetical)
CVSS: 7.5 (High)
EPSS: 0.85 (85%)
KEV: No
Asset: High (user-facing API)
Exposure: Internet-facing

Calculation:
Priority Score = (7.5 × 0.3) + (85 × 0.3) + (0 × 50) + (0.7 × 0.2) + (1 × 0.2)
               = 2.25 + 25.5 + 0 + 0.14 + 0.2
               = 28.09

Result: P1 - High
SLA: 7 days
Action: Prioritize in current sprint
Reasoning: High exploitation probability + Internet-facing = high risk

---

Summary

Quick Reference:

P0: KEV + Internet + Critical asset → 24 hours
P1: CVSS ≥ 9.0 OR (CVSS ≥ 7.0 AND EPSS ≥ 0.1) → 7 days
P2: CVSS 7.0-8.9 OR EPSS ≥ 0.05 → 30 days
P3: CVSS 4.0-6.9, EPSS < 0.05 → 90 days
P4: CVSS < 4.0 → No SLA

Data Sources:

CVSS: NVD API, Trivy scans, vendor advisories
EPSS: https://api.first.org/data/v1/epss
KEV: https://www.cisa.gov/known-exploited-vulnerabilities-catalog

Automation: See examples/prioritization/ for complete scripts.

Vulnerability Remediation Workflows

Patterns for tracking, managing, and remediating vulnerabilities with SLAs and automation.

Table of Contents

1. SLA Tracking 2. False Positive Management 3. Automated Remediation 4. Metrics and Reporting

---

SLA Tracking

Priority-Based SLAs

Automated SLA Tracker

#!/bin/bash
# scripts/sla-tracker.sh

# Track vulnerability remediation SLAs

SCAN_RESULTS="scan-results.json"
KEV_CATALOG="kev.json"
OUTPUT="sla-report.json"

# Download KEV catalog
curl -s -o "$KEV_CATALOG" https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json

# Parse vulnerabilities and calculate SLA
jq --slurpfile kev "$KEV_CATALOG" '
.Results[].Vulnerabilities[] |
{
  cve: .VulnerabilityID,
  severity: .Severity,
  found_date: (.PublishedDate | fromdateiso8601),
  cvss: .CVSS.nvd.V3Score,
  package: .PkgName,
  fixed_version: .FixedVersion,
  in_kev: ([($kev[0].vulnerabilities[] | select(.cveID == .VulnerabilityID))] | length > 0)
} |
# Calculate priority and SLA
if .in_kev then
  .priority = "P0" | .sla_hours = 24
elif .cvss >= 9.0 then
  .priority = "P1" | .sla_hours = 168
elif .cvss >= 7.0 then
  .priority = "P2" | .sla_hours = 720
elif .cvss >= 4.0 then
  .priority = "P3" | .sla_hours = 2160
else
  .priority = "P4" | .sla_hours = null
end |
# Calculate deadline
if .sla_hours then
  .deadline = (.found_date + .sla_hours * 3600) | .overdue = (now > .deadline)
else
  .deadline = null | .overdue = false
end
' "$SCAN_RESULTS" > "$OUTPUT"

# Generate summary
echo "SLA Summary:"
jq -r '
group_by(.priority) |
map({
  priority: .[0].priority,
  count: length,
  overdue: ([.[] | select(.overdue == true)] | length)
}) |
.[]
| "\(.priority): \(.count) total, \(.overdue) overdue"
' "$OUTPUT"

False Positive Management

Suppression File (.trivyignore)

# CVE-2023-12345
# Reason: False positive - vulnerability not applicable to our usage
# Verified by: security-team@example.com
# Date: 2025-12-04
# Review date: 2026-03-04
CVE-2023-12345

# CVE-2023-67890
# Reason: Risk accepted - fix requires major refactor, compensating controls in place
# Approved by: CISO
# Compensating controls: WAF rules, network isolation
# Review date: 2025-06-04
CVE-2023-67890

# Development dependencies (not in production)
CVE-2023-11111  # webpack-dev-server (devDependency only)

False Positive Workflow

# .github/workflows/manage-false-positives.yml
name: False Positive Management

on:
  issues:
    types: [labeled]

jobs:
  add-suppression:
    if: github.event.label.name == 'false-positive'
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Extract CVE from issue
        id: cve
        run: |
          CVE=$(echo "${{ github.event.issue.title }}" | grep -oP 'CVE-\d{4}-\d+')
          echo "cve=$CVE" >> $GITHUB_OUTPUT

      - name: Add to .trivyignore
        run: |
          echo "" >> .trivyignore
          echo "# ${{ steps.cve.outputs.cve }}" >> .trivyignore
          echo "# Reason: ${{ github.event.issue.body }}" >> .trivyignore
          echo "# Added by: ${{ github.event.issue.user.login }}" >> .trivyignore
          echo "# Date: $(date +%Y-%m-%d)" >> .trivyignore
          echo "${{ steps.cve.outputs.cve }}" >> .trivyignore

      - name: Create PR
        run: |
          git config user.name "github-actions[bot]"
          git config user.email "github-actions[bot]@users.noreply.github.com"
          git checkout -b suppress-${{ steps.cve.outputs.cve }}
          git add .trivyignore
          git commit -m "chore: Suppress ${{ steps.cve.outputs.cve }} (false positive)"
          git push origin suppress-${{ steps.cve.outputs.cve }}
          gh pr create --title "Suppress ${{ steps.cve.outputs.cve }}" \
                       --body "Closes #${{ github.event.issue.number }}" \
                       --label "security,false-positive"
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

Automated Remediation

Dependency Update Automation

name: Automated Vulnerability Remediation

on:
  schedule:
    - cron: '0 0 * * *'  # Daily at midnight
  workflow_dispatch:

jobs:
  scan-and-remediate:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Scan for vulnerabilities
        id: scan
        run: |
          trivy image myapp:latest --format json --output scan.json
          FIXABLE=$(jq '[.Results[].Vulnerabilities[] | select(.Severity == "HIGH" or .Severity == "CRITICAL") | select(.FixedVersion != "")] | length' scan.json)
          echo "fixable_count=$FIXABLE" >> $GITHUB_OUTPUT

      - name: Update dependencies (Node.js)
        if: steps.scan.outputs.fixable_count > 0
        run: |
          npm update
          npm audit fix

      - name: Update dependencies (Python)
        if: steps.scan.outputs.fixable_count > 0
        run: |
          pip install pip-audit
          pip-audit --fix

      - name: Rebuild and re-scan
        if: steps.scan.outputs.fixable_count > 0
        run: |
          docker build -t myapp:remediation .
          trivy image myapp:remediation --format json --output scan-after.json

      - name: Create remediation PR
        if: steps.scan.outputs.fixable_count > 0
        run: |
          git config user.name "security-bot"
          git config user.email "security-bot@example.com"
          git checkout -b security/auto-remediation-$(date +%Y%m%d)
          git add package*.json requirements.txt
          git commit -m "security: Fix ${{ steps.scan.outputs.fixable_count }} vulnerabilities"
          git push origin security/auto-remediation-$(date +%Y%m%d)

          gh pr create \
            --title "Security: Automated vulnerability remediation" \
            --body "Fixes ${{ steps.scan.outputs.fixable_count }} fixable vulnerabilities" \
            --label "security,automated"
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

Metrics and Reporting

Vulnerability Dashboard Metrics

#!/usr/bin/env python3
# scripts/vulnerability-metrics.py

import json
import sys
from datetime import datetime

def analyze_scan_results(scan_file):
    with open(scan_file) as f:
        scan_data = json.load(f)

    metrics = {
        'total_vulnerabilities': 0,
        'by_severity': {'CRITICAL': 0, 'HIGH': 0, 'MEDIUM': 0, 'LOW': 0},
        'fixable': 0,
        'unfixable': 0,
        'by_priority': {'P0': 0, 'P1': 0, 'P2': 0, 'P3': 0, 'P4': 0},
        'scan_date': datetime.now().isoformat()
    }

    for result in scan_data.get('Results', []):
        for vuln in result.get('Vulnerabilities', []):
            metrics['total_vulnerabilities'] += 1
            severity = vuln.get('Severity', 'UNKNOWN')
            metrics['by_severity'][severity] = metrics['by_severity'].get(severity, 0) + 1

            if vuln.get('FixedVersion'):
                metrics['fixable'] += 1
            else:
                metrics['unfixable'] += 1

    return metrics

if __name__ == '__main__':
    metrics = analyze_scan_results(sys.argv[1] if len(sys.argv) > 1 else 'scan.json')
    print(json.dumps(metrics, indent=2))

Executive Report Generation

#!/bin/bash
# scripts/executive-report.sh

SCAN_FILE="scan.json"
REPORT_FILE="security-report.md"

cat > "$REPORT_FILE" << EOF
# Security Vulnerability Report
**Date:** $(date +%Y-%m-%d)
**Scan Date:** $(jq -r '.CreatedAt' "$SCAN_FILE")

## Executive Summary

$(jq -r '
[.Results[].Vulnerabilities[]] |
{
  total: length,
  critical: ([.[] | select(.Severity == "CRITICAL")] | length),
  high: ([.[] | select(.Severity == "HIGH")] | length),
  medium: ([.[] | select(.Severity == "MEDIUM")] | length),
  low: ([.[] | select(.Severity == "LOW")] | length)
} |
"- **Total Vulnerabilities:** \(.total)
- **Critical:** \(.critical)
- **High:** \(.high)
- **Medium:** \(.medium)
- **Low:** \(.low)"
' "$SCAN_FILE")

## Priority Breakdown

$(jq -r '
[.Results[].Vulnerabilities[]] |
group_by(
  if .CVSS.nvd.V3Score >= 9.0 then "P1"
  elif .CVSS.nvd.V3Score >= 7.0 then "P2"
  elif .CVSS.nvd.V3Score >= 4.0 then "P3"
  else "P4"
  end
) |
map({priority: .[0], count: length}) |
.[] |
"- **\(.priority):** \(.count) vulnerabilities"
' "$SCAN_FILE")

## Action Items

### Immediate (P0/P1)
$(jq -r '
[.Results[].Vulnerabilities[] | select(.CVSS.nvd.V3Score >= 9.0)] |
.[] |
"- [ ] Fix \(.VulnerabilityID) in \(.PkgName) (CVSS: \(.CVSS.nvd.V3Score))"
' "$SCAN_FILE" | head -10)

### Upcoming Sprint (P2)
$(jq -r '
[.Results[].Vulnerabilities[] | select(.CVSS.nvd.V3Score >= 7.0 and .CVSS.nvd.V3Score < 9.0)] |
length |
"- \(.) vulnerabilities to address in upcoming sprint"
' "$SCAN_FILE")

---
*Generated automatically by security scanning pipeline*
EOF

echo "Report generated: $REPORT_FILE"

See complete scripts in scripts/ directory.

SBOM Generation and Management Guide

Complete patterns for Software Bill of Materials (SBOM) generation, storage, consumption, and compliance.

Table of Contents

1. SBOM Fundamentals 2. CycloneDX vs SPDX 3. Generation Tools 4. Generation Patterns 5. SBOM Storage and Distribution 6. SBOM Consumption 7. Compliance Requirements 8. Best Practices

---

SBOM Fundamentals

What is an SBOM?

A Software Bill of Materials (SBOM) is a formal, structured list of components, libraries, and modules required to build software. Think of it as an "ingredients label" for software.

Core Elements (NTIA Minimum):

• Supplier name
• Component name
• Version of component
• Unique identifier (PURL, CPE)
• Dependency relationships
• Author of SBOM data
• Timestamp

Why SBOMs Matter

Regulatory Drivers:

• Executive Order 14028 (US Federal software procurement)
• NTIA minimum elements for SBOM
• Industry standards (OWASP, Linux Foundation)
• Customer security requirements

Security Benefits:

• Vulnerability tracking: Know what's affected by new CVEs
• Supply chain transparency: Understand dependency risks
• Incident response: Quickly identify affected systems
• License compliance: Track open-source licenses

Operational Benefits:

• Faster vulnerability remediation
• Automated security scanning
• Compliance evidence generation
• Supply chain risk management

---

CycloneDX vs SPDX

Format Comparison

When to Use CycloneDX

Best For:

• DevSecOps and security-focused teams
• Vulnerability tracking and management
• Fast CI/CD pipelines (smaller files)
• Automated security scanning
• Container security workflows
• Agile development environments

Example Use Cases:

✓ Container image SBOM for vulnerability scanning
✓ CI/CD pipeline artifact generation
✓ Automated dependency tracking
✓ Security dashboard integration
✓ Rapid SBOM generation (< 1 minute)

When to Use SPDX

Best For:

• Legal and compliance teams
• License compliance audits
• Government/defense contracts (ISO standard)
• Comprehensive legal metadata required
• Open-source license tracking
• Long-term archival

Example Use Cases:

✓ License compliance audits
✓ Federal contract requirements
✓ Open-source license tracking
✓ Legal risk assessment
✓ Export compliance documentation

Recommendation by Scenario

Scenario 1: DevSecOps Team

Format: CycloneDX JSON
Reason: Security-focused, fast, native vulnerability references
Tools: Trivy, Syft, cdxgen

Scenario 2: Legal/Compliance Team

Format: SPDX 2.3
Reason: Comprehensive license data, ISO standard
Tools: Microsoft SBOM Tool, Syft

Scenario 3: Dual Requirements

Format: Both (generate both formats)
Reason: Security AND legal needs
Tools: Syft (supports both), or Trivy + Microsoft SBOM Tool

Scenario 4: Federal/Government

Format: SPDX (preferred) or CycloneDX (accepted)
Reason: ISO standard alignment, government preference
Tools: Microsoft SBOM Tool, Tern

---

Generation Tools

Multi-Format Tools

Trivy (Recommended - All-in-One)

Supports: CycloneDX, SPDX Best For: Container images, fast CI/CD, comprehensive coverage

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

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

# Scan filesystem
trivy fs --format cyclonedx --output sbom.json .

# Include vulnerabilities in SBOM
trivy image --format cyclonedx --scanners vuln --output sbom-with-vulns.json alpine:latest

Strengths:

• All-in-one: Scan + SBOM generation
• Fast: Optimized for CI/CD
• Multiple targets: Containers, filesystems, Git repos
• Vulnerability integration: Include vulnerabilities in SBOM

---

Syft (Accuracy-Focused)

Supports: CycloneDX, SPDX, Syft JSON Best For: High accuracy, SBOM-first workflows, Anchore ecosystem

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

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

# Multiple formats at once
syft alpine:latest -o cyclonedx-json=sbom-cdx.json -o spdx-json=sbom-spdx.json

# Scan directory
syft dir:. -o cyclonedx-json=sbom.json

# Scan with cataloging options
syft packages alpine:latest --scope all-layers -o cyclonedx-json

Strengths:

• High accuracy: Precise package detection
• Multi-format: CycloneDX, SPDX, custom JSON
• Flexible: Many output formats and options
• Anchore integration: Works with Grype for scanning

---

cdxgen (Multi-Language)

Supports: CycloneDX only Best For: Multi-language projects, Node.js/Python/Java focus

# Install
npm install -g @cyclonedx/cdxgen

# Generate SBOM
cdxgen -o sbom.json .

# Specific project type
cdxgen -t node -o sbom.json .

# With evidence (build info)
cdxgen --evidence -o sbom.json .

# Include dev dependencies
cdxgen --include-dev -o sbom.json .

Strengths:

• 20+ languages: Node.js, Python, Java, Go, PHP, .NET, etc.
• OWASP official: Maintained by CycloneDX team
• Evidence tracking: Build and deployment metadata
• Container support: Docker and OCI images

---

Language-Specific Tools

Node.js

# CycloneDX BOM
npx @cyclonedx/cyclonedx-npm --output-file sbom.json

# SPDX
npm install -g spdx-sbom-generator
spdx-sbom-generator -p .

Python

# CycloneDX
pip install cyclonedx-bom
cyclonedx-py -o sbom.json

# Syft (recommended)
syft dir:. -o cyclonedx-json=sbom.json

Java (Maven)

<!-- pom.xml -->
<plugin>
  <groupId>org.cyclonedx</groupId>
  <artifactId>cyclonedx-maven-plugin</artifactId>
  <version>2.7.9</version>
  <executions>
    <execution>
      <goals>
        <goal>makeAggregateBom</goal>
      </goals>
    </execution>
  </executions>
</plugin>

# Generate SBOM
mvn cyclonedx:makeAggregateBom

Go

# Syft
syft packages dir:. -o cyclonedx-json=sbom.json

# cdxgen
cdxgen -t go -o sbom.json .

Rust

# cargo-sbom
cargo install cargo-sbom
cargo sbom --output-format cyclonedx_json_1_4 > sbom.json

---

Generation Patterns

Pattern 1: CI/CD Automatic Generation

GitHub Actions:

name: Generate SBOM

on:
  push:
    branches: [main]
  release:
    types: [published]

jobs:
  sbom:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Build Docker image
        run: docker build -t myapp:${{ github.sha }} .

      - name: Generate CycloneDX SBOM (security)
        run: |
          trivy image --format cyclonedx \
            --output sbom-cyclonedx.json \
            myapp:${{ github.sha }}

      - name: Generate SPDX SBOM (compliance)
        run: |
          syft myapp:${{ github.sha }} \
            -o spdx-json=sbom-spdx.json

      - name: Upload SBOM artifacts
        uses: actions/upload-artifact@v3
        with:
          name: sboms
          path: |
            sbom-cyclonedx.json
            sbom-spdx.json
          retention-days: 90

      - name: Attach SBOM to release (if release event)
        if: github.event_name == 'release'
        run: |
          gh release upload ${{ github.event.release.tag_name }} \
            sbom-cyclonedx.json sbom-spdx.json
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

GitLab CI:

sbom-generation:
  stage: build
  image: aquasec/trivy:latest
  script:
    - trivy image --format cyclonedx --output sbom.json $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA
  artifacts:
    paths:
      - sbom.json
    reports:
      cyclonedx: sbom.json
    expire_in: 90 days

---

Pattern 2: Multi-Stage Docker Build with SBOM

Dockerfile:

# Stage 1: Build application
FROM node:20-alpine AS builder
WORKDIR /app
COPY package*.json ./
RUN npm ci --production

# Generate SBOM during build
RUN npx @cyclonedx/cyclonedx-npm \
    --output-file /tmp/sbom.json \
    --output-format JSON \
    --short-PURLs

# Stage 2: Runtime
FROM node:20-alpine AS runtime
WORKDIR /app

# Copy application
COPY --from=builder /app/node_modules ./node_modules
COPY . .

# Include SBOM in image
COPY --from=builder /tmp/sbom.json /app/sbom.json

# Label with SBOM location
LABEL org.opencontainers.image.sbom=/app/sbom.json

CMD ["node", "index.js"]

---

Pattern 3: SBOM as OCI Artifact

Store SBOM alongside container image in registry:

# Install ORAS (OCI Registry As Storage)
brew install oras

# Generate SBOM
trivy image --format cyclonedx --output sbom.json myapp:latest

# Attach SBOM to image as OCI artifact
oras attach myregistry.io/myapp:latest \
  --artifact-type application/vnd.cyclonedx+json \
  sbom.json:application/vnd.cyclonedx+json

# Discover attached artifacts
oras discover myregistry.io/myapp:latest

# Pull SBOM
oras pull myregistry.io/myapp:latest --artifact-type application/vnd.cyclonedx+json

---

Pattern 4: SBOM Enrichment with Vulnerabilities

Include vulnerability data in SBOM:

# Generate SBOM with vulnerabilities (CycloneDX VEX)
trivy image --format cyclonedx \
  --scanners vuln \
  --output sbom-with-vulns.json \
  myapp:latest

# Separate SBOM and vulnerability report
trivy image --format cyclonedx --output sbom.json myapp:latest
trivy image --format json --output vulns.json myapp:latest

---

SBOM Storage and Distribution

Storage Options

1. Version Control (Git)

Best For: Tracking SBOM changes over time

# Store in repository
git add sbom.json
git commit -m "chore: Update SBOM for v1.2.0"
git tag v1.2.0
git push --tags

Structure:

project/
├── sbom/
│   ├── sbom-v1.0.0.json
│   ├── sbom-v1.1.0.json
│   └── sbom-latest.json
└── src/

---

2. Artifact Repository

Best For: Enterprise artifact management

Artifactory:

# Upload to Artifactory
curl -H "X-JFrog-Art-Api:$API_KEY" \
  -T sbom.json \
  "https://artifactory.example.com/artifactory/sbom-repo/myapp/1.0.0/sbom.json"

Nexus:

# Upload to Nexus
curl -u admin:admin123 \
  --upload-file sbom.json \
  "https://nexus.example.com/repository/sbom-repo/myapp/1.0.0/sbom.json"

---

3. SBOM Management Platforms

Dependency Track:

# Upload SBOM
curl -X PUT \
  "https://dtrack.example.com/api/v1/bom" \
  -H "X-Api-Key: $API_KEY" \
  -H "Content-Type: application/json" \
  -d @sbom.json

Kubernetes ConfigMap:

apiVersion: v1
kind: ConfigMap
metadata:
  name: myapp-sbom
  namespace: production
data:
  sbom.json: |
    {
      "bomFormat": "CycloneDX",
      "specVersion": "1.4",
      ...
    }

---

4. Cloud Storage

AWS S3:

# Upload to S3
aws s3 cp sbom.json s3://company-sboms/myapp/v1.0.0/sbom.json

# Make public (if needed for customers)
aws s3api put-object-acl \
  --bucket company-sboms \
  --key myapp/v1.0.0/sbom.json \
  --acl public-read

Google Cloud Storage:

# Upload to GCS
gsutil cp sbom.json gs://company-sboms/myapp/v1.0.0/sbom.json

---

Distribution Methods

1. Include in Software Package

# Include SBOM in release tarball
tar -czf myapp-v1.0.0.tar.gz myapp/ sbom.json

# Include in installer
dpkg-deb --build --root-owner-group myapp_1.0.0_amd64
# (SBOM in /usr/share/doc/myapp/sbom.json)

---

2. Publish with Release

GitHub Releases:

# Create release with SBOM
gh release create v1.0.0 \
  --title "Release v1.0.0" \
  --notes "See CHANGELOG.md" \
  myapp-v1.0.0.tar.gz \
  sbom-cyclonedx.json \
  sbom-spdx.json

---

3. API Endpoint

Serve SBOM via API for automated consumption:

// Express.js example
app.get('/sbom/:version', (req, res) => {
  const sbomPath = `./sboms/sbom-${req.params.version}.json`;
  res.sendFile(sbomPath);
});

// https://api.example.com/sbom/1.0.0

---

SBOM Consumption

Scanning SBOM Instead of Image

Faster CI/CD: Scan SBOM (seconds) vs. re-scan image (minutes)

# Generate SBOM once (build stage)
trivy image --format cyclonedx --output sbom.json myapp:latest

# Scan SBOM in subsequent stages (fast)
trivy sbom sbom.json --severity HIGH,CRITICAL

# With Grype
grype sbom:sbom.json --fail-on high

GitHub Actions Pattern:

build:
  runs-on: ubuntu-latest
  steps:
    - run: docker build -t myapp:${{ github.sha }} .
    - run: trivy image --format cyclonedx --output sbom.json myapp:${{ github.sha }}
    - uses: actions/upload-artifact@v3
      with:
        name: sbom
        path: sbom.json

scan-pr:
  runs-on: ubuntu-latest
  needs: build
  steps:
    - uses: actions/download-artifact@v3
      with:
        name: sbom
    - run: trivy sbom sbom.json --severity HIGH,CRITICAL --exit-code 1

---

SBOM Analysis and Queries

Query SBOM with jq:

# List all components
jq '.components[] | {name: .name, version: .version}' sbom.json

# Find specific dependency
jq '.components[] | select(.name == "lodash")' sbom.json

# Count dependencies
jq '.components | length' sbom.json

# List licenses
jq '.components[].licenses[].license.id' sbom.json | sort -u

# Find vulnerabilities (if included)
jq '.vulnerabilities[] | {id: .id, severity: .ratings[0].severity}' sbom.json

Python Script Example:

import json

with open('sbom.json') as f:
    sbom = json.load(f)

# Extract components
components = sbom.get('components', [])

# Group by license
licenses = {}
for comp in components:
    for lic in comp.get('licenses', []):
        license_id = lic['license']['id']
        licenses.setdefault(license_id, []).append(comp['name'])

# Report
for license, packages in licenses.items():
    print(f"{license}: {len(packages)} packages")

---

SBOM Diffing

Compare SBOMs between versions:

# Generate SBOMs for two versions
trivy image --format cyclonedx --output sbom-old.json myapp:v1.0.0
trivy image --format cyclonedx --output sbom-new.json myapp:v1.1.0

# Extract component lists
jq -r '.components[] | "\(.name)@\(.version)"' sbom-old.json | sort > old-deps.txt
jq -r '.components[] | "\(.name)@\(.version)"' sbom-new.json | sort > new-deps.txt

# Show differences
diff old-deps.txt new-deps.txt

# Added dependencies
comm -13 old-deps.txt new-deps.txt

# Removed dependencies
comm -23 old-deps.txt new-deps.txt

---

Compliance Requirements

NTIA Minimum Elements

Required fields for SBOM compliance:

1. Supplier Name: Who provides the component 2. Component Name: Name of the software component 3. Version: Version identifier 4. Unique Identifier: PURL, CPE, or similar 5. Dependency Relationships: Component graph 6. Author of SBOM: Who created the SBOM 7. Timestamp: When SBOM was created

Validation:

# Verify NTIA compliance
# Check for required fields in CycloneDX
jq '.metadata.timestamp, .metadata.authors, .components[0] | {name, version, purl}' sbom.json

---

Executive Order 14028 (Federal)

Requirements:

• SBOM for all software sold to federal government
• Machine-readable format (CycloneDX or SPDX)
• NTIA minimum elements included
• Regular updates with vulnerability data

Recommended Format: SPDX (ISO standard preferred by government)

---

Industry Standards

OWASP CycloneDX:

• Current version: 1.5
• Security-focused SBOM standard
• Used by: Trivy, Syft, cdxgen, Dependency Track

SPDX:

• Current version: 2.3
• ISO/IEC 5962:2021
• Used by: Linux Foundation, Microsoft SBOM Tool

---

Best Practices

1. Generate SBOM on Every Build

# Always generate SBOM
- name: Generate SBOM
  run: trivy image --format cyclonedx --output sbom.json $IMAGE
  if: always()  # Generate even if tests fail

2. Store with Artifacts

# Upload SBOM with build artifacts
- uses: actions/upload-artifact@v3
  with:
    name: release-artifacts
    path: |
      myapp-binary
      sbom.json
      sbom-spdx.json

3. Version SBOMs

# Include version in filename
trivy image --format cyclonedx --output sbom-v${VERSION}.json myapp:${VERSION}

# Tag SBOMs in Git
git tag sbom-v1.0.0

4. Provide Multiple Formats

# Generate both CycloneDX (security) and SPDX (compliance)
trivy image --format cyclonedx --output sbom-cyclonedx.json myapp:latest
trivy image --format spdx-json --output sbom-spdx.json myapp:latest

5. Automate Distribution

# Automatically attach to releases
- name: Upload to release
  if: github.event_name == 'release'
  run: gh release upload ${{ github.ref_name }} sbom*.json

6. Sign SBOMs

# Sign with cosign
cosign sign-blob --key cosign.key sbom.json > sbom.json.sig

# Verify
cosign verify-blob --key cosign.pub --signature sbom.json.sig sbom.json

7. Include in Documentation

# README.md

## Security

Software Bill of Materials (SBOM) available:
- CycloneDX: [sbom-cyclonedx.json](./sbom-cyclonedx.json)
- SPDX: [sbom-spdx.json](./sbom-spdx.json)

Generated with: Trivy v0.48.0
Last updated: 2025-12-04

8. Continuous Monitoring

# Upload to Dependency Track for continuous monitoring
curl -X PUT "https://dtrack.example.com/api/v1/bom" \
  -H "X-Api-Key: $API_KEY" \
  -d @sbom.json

# Get notifications on new vulnerabilities

---

Troubleshooting

Common Issues

1. Large SBOM Files

# Problem: SBOM is 50MB+
# Solution: Exclude unnecessary components

# Exclude dev dependencies
trivy image --skip-dirs node_modules --format cyclonedx myapp:latest

# Syft: scope production only
syft myapp:latest --scope squashed -o cyclonedx-json

2. Missing Dependencies

# Problem: Not all dependencies detected
# Solution: Use multiple tools and merge

# Generate with multiple tools
trivy image --format cyclonedx --output sbom-trivy.json myapp:latest
syft myapp:latest -o cyclonedx-json=sbom-syft.json

# Manual merge or use cdx-merge tool

3. Incompatible Format Versions

# Problem: Tool doesn't support CycloneDX 1.5
# Solution: Specify older version

# Syft with specific version
syft myapp:latest --output cyclonedx-1.4-json=sbom.json

---

Summary

Quick Decision Guide:

Security/DevSecOps → CycloneDX + Trivy/Syft
Legal/Compliance → SPDX + Microsoft SBOM Tool / Syft
Both requirements → Generate both formats
Federal/Government → SPDX (ISO standard)
Fast CI/CD → CycloneDX JSON

Essential Commands:

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

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

# Scan SBOM (fast)
trivy sbom sbom.json --severity HIGH,CRITICAL

Vulnerability Scanning Tool Selection Guide

Complete decision frameworks for selecting appropriate security scanning tools across all layers.

Table of Contents

1. Container Scanning Tools 2. SAST Tools 3. DAST Tools 4. SCA Tools 5. Secret Scanning Tools 6. Decision Flowcharts 7. Tool Comparison Matrices

---

Container Scanning Tools

Trivy (Primary Recommendation)

When to Use:

• Default choice for most container scanning needs
• Need comprehensive coverage (OS, languages, secrets, misconfig)
• Fast CI/CD pipelines (< 1 minute scans)
• SBOM generation required
• Kubernetes environments (manifest scanning)
• Teams needing all-in-one solution

Strengths:

• Comprehensive: OS packages, language libraries, secrets, misconfigurations, licenses
• Fast: Parallel scanning, optimized database
• Zero setup: Single binary, works out-of-the-box
• SBOM native: Generate and consume CycloneDX/SPDX
• Multi-target: Container images, filesystems, Git repos, K8s manifests, Terraform
• Active development: 100+ releases/year, responsive community

Limitations:

• Can have false positives (mitigated with .trivyignore)
• Database updates required (automatic but adds startup time)

Installation:

# macOS
brew install trivy

# Linux
curl -sfL https://raw.githubusercontent.com/aquasecurity/trivy/main/contrib/install.sh | sh -s -- -b /usr/local/bin

# Docker
docker pull aquasec/trivy:latest

# Binary download
wget https://github.com/aquasecurity/trivy/releases/download/v0.48.0/trivy_0.48.0_Linux-64bit.tar.gz

Example Usage:

# Basic scan
trivy image alpine:latest

# CI/CD with severity filter
trivy image --severity HIGH,CRITICAL --exit-code 1 myapp:latest

# Generate SBOM
trivy image --format cyclonedx --output sbom.json myapp:latest

# Scan filesystem
trivy fs --scanners vuln,secret,misconfig /path/to/project

# Scan Kubernetes
trivy config deployment.yaml

Best Practices:

# .trivy.yaml
severity: HIGH,CRITICAL
exit-code: 1
ignore-unfixed: true
vuln-type: os,library
skip-dirs:
  - node_modules
  - vendor
  - test
ignorefile: .trivyignore

---

Grype (Alternative - Accuracy Focus)

When to Use:

• False positive sensitivity critical
• SBOM-first workflows (pair with Syft)
• Need second opinion validation
• Anchore ecosystem users
• Accuracy more important than comprehensiveness

Strengths:

• Minimal false positives: Precise package version matching
• Syft integration: Best-in-class SBOM generation
• Lightweight: No database required
• Fast: Comparable to Trivy
• Clear output: Easy to parse and understand

Limitations:

• Requires Syft for SBOM generation (two tools vs. Trivy's one)
• Less comprehensive than Trivy (no misconfig, limited secret scanning)
• Credential disclosure CVE (CVE-2025-65965) - Use v0.104.1+

Installation:

# macOS
brew install grype

# Linux
curl -sSfL https://raw.githubusercontent.com/anchore/grype/main/install.sh | sh -s -- -b /usr/local/bin

# Docker
docker pull anchore/grype:latest

Example Usage:

# Basic scan
grype alpine:latest

# With severity threshold
grype alpine:latest --fail-on high

# Scan SBOM
grype sbom:./sbom.json

# Exclude paths
grype dir:. --exclude './node_modules/**'

# Syft + Grype workflow
syft alpine:latest -o json | grype --fail-on critical

Best Practices:

# .grype.yaml
fail-on-severity: high
output: table
exclude:
  - CVE-2023-12345  # False positive

---

Snyk Container (Commercial)

When to Use:

• Budget for commercial tooling
• Developer productivity priority
• Need automated remediation PRs
• Want unified platform (container + SCA + SAST + IaC)
• Require priority intelligence (exploit maturity)

Strengths:

• Developer-first UX: Clear fix guidance, base image recommendations
• Automated remediation: PRs for dependency updates
• Priority Intelligence: Risk-based prioritization with exploit data
• IDE integration: Real-time feedback in VS Code, IntelliJ
• Comprehensive: Container, code, dependencies, IaC in one platform

Limitations:

• Commercial license required (free tier limited)
• Requires internet connectivity for scanning
• Less customizable than open-source tools

Example Usage:

# Install
npm install -g snyk

# Authenticate
snyk auth

# Scan container
snyk container test alpine:latest

# Monitor in dashboard
snyk container monitor alpine:latest --project-name=myapp

# Automated fixes
snyk container test --file=Dockerfile --exclude-base-image-vulns

---

SAST Tools

Semgrep (Primary Recommendation)

When to Use:

• Need fast, customizable static analysis
• Multi-language projects
• Custom security rules required
• CI/CD integration (< 5 minute scans)
• Open-source preference

Strengths:

• Fast: Semantic pattern matching, not full compilation
• Multi-language: 30+ languages supported
• Customizable: Write custom rules in YAML
• Low false positives: Context-aware matching
• CI/CD native: GitHub Actions, GitLab CI, pre-commit hooks

Limitations:

• Requires rule customization for best results
• Less comprehensive than commercial tools (fewer rules out-of-box)

Installation:

# macOS
brew install semgrep

# pip
pip install semgrep

# Docker
docker pull returntocorp/semgrep

Example Usage:

# Scan with OWASP ruleset
semgrep --config=p/security-audit .

# Multiple rulesets
semgrep --config=p/owasp-top-ten --config=p/secrets .

# CI/CD mode (fail on findings)
semgrep ci

# Custom rules
semgrep --config=rules/custom-security.yaml .

---

Snyk Code (Commercial)

When to Use:

• Developer-first experience priority
• IDE integration required
• Need clear fix guidance
• Want AI-powered analysis

Strengths:

• IDE plugins: Real-time feedback in editor
• Developer guidance: Clear explanations and fix suggestions
• AI-powered: ML-based vulnerability detection
• Fast: Incremental scanning in IDE

---

SonarQube (Enterprise)

When to Use:

• Enterprise code quality + security
• Need centralized dashboard
• Compliance requirements (audit trails)
• Long-term trend analysis

Strengths:

• Comprehensive: Code quality + security
• Quality gates: Enforce thresholds
• Historical analysis: Track technical debt over time
• Enterprise features: LDAP, SSO, audit logs

---

DAST Tools

OWASP ZAP (Primary Recommendation)

When to Use:

• Need open-source full-featured DAST
• Manual + automated testing required
• API security testing
• Budget constraints

Strengths:

• Full-featured: Active scan, passive scan, fuzzing, API testing
• Extensible: Plugins and scripts
• Active community: Well-documented, many resources
• Free: No licensing costs

Installation:

# Docker
docker pull owasp/zap2docker-stable

# macOS
brew install --cask owasp-zap

# Download
# https://www.zaproxy.org/download/

Example Usage:

# Baseline scan (non-intrusive)
docker run -v $(pwd):/zap/wrk/:rw -t owasp/zap2docker-stable \
  zap-baseline.py -t https://example.com -r report.html

# Full scan (intrusive)
docker run -v $(pwd):/zap/wrk/:rw -t owasp/zap2docker-stable \
  zap-full-scan.py -t https://example.com -r report.html

# API scan
docker run -v $(pwd):/zap/wrk/:rw -t owasp/zap2docker-stable \
  zap-api-scan.py -t https://api.example.com/openapi.json -f openapi

---

StackHawk (Commercial - CI/CD Native)

When to Use:

• Modern CI/CD native DAST required
• Need developer-friendly output
• API-first applications
• Budget for commercial tool

Strengths:

• CI/CD native: Built for automated pipelines
• Developer-focused: Clear, actionable results
• API testing: GraphQL, REST, gRPC support
• Fast: Optimized for CI/CD speed

---

SCA Tools

Dependabot (GitHub Native)

When to Use:

• Using GitHub
• Need automated dependency updates
• Free option required
• Simple dependency scanning sufficient

Strengths:

• Native GitHub integration: Zero setup
• Automated PRs: Dependency updates with changelogs
• Free: Included with GitHub
• Security alerts: Integrated with GitHub Security

Configuration:

# .github/dependabot.yml
version: 2
updates:
  - package-ecosystem: npm
    directory: "/"
    schedule:
      interval: weekly
    open-pull-requests-limit: 10

---

Renovate (Advanced Automation)

When to Use:

• Need advanced customization
• Multi-platform (GitHub, GitLab, Bitbucket, Azure DevOps)
• Complex dependency update strategies
• Monorepo support required

Strengths:

• Highly customizable: Granular control over updates
• Multi-platform: Works across Git platforms
• Smart grouping: Group related updates
• Flexible scheduling: Time-based, on-demand, manual approval

Configuration:

{
  "extends": ["config:base"],
  "schedule": ["after 10pm every weekday"],
  "packageRules": [
    {
      "matchUpdateTypes": ["minor", "patch"],
      "automerge": true
    }
  ]
}

---

Snyk Open Source (Commercial)

When to Use:

• Comprehensive commercial solution required
• Need largest vulnerability database
• Want automated fix PRs with testing
• Unified platform preference

Strengths:

• Largest database: Most comprehensive vulnerability data
• Fix PRs: Automated updates with CI/CD integration
• Priority Intelligence: Risk-based prioritization
• Unified platform: SCA + SAST + Container + IaC

---

Secret Scanning Tools

Gitleaks (Primary Recommendation)

When to Use:

• Need fast, open-source secret scanning
• CI/CD integration required
• Custom rule configuration needed
• Pre-commit hooks

Strengths:

• Fast: Optimized scanning engine
• Configurable: Custom rules via TOML
• CI/CD ready: Exit codes, JSON output
• Pre-commit support: Prevent secrets before commit

Installation:

# macOS
brew install gitleaks

# Docker
docker pull zricethezav/gitleaks:latest

# Binary
wget https://github.com/gitleaks/gitleaks/releases/download/v8.18.0/gitleaks_8.18.0_linux_x64.tar.gz

Example Usage:

# Scan current directory
gitleaks detect --source . --verbose

# Scan specific commit range
gitleaks detect --log-opts="--since=2023-01-01"

# Pre-commit hook
gitleaks protect --staged --verbose

# CI/CD mode (exit code on findings)
gitleaks detect --source . --exit-code 1

Configuration:

# .gitleaks.toml
title = "Gitleaks Config"

[extend]
useDefault = true

[[rules]]
description = "Custom AWS Key"
regex = '''AKIA[0-9A-Z]{16}'''
tags = ["aws", "key"]

---

TruffleHog (Entropy Detection)

When to Use:

• Need entropy-based detection
• Want to find secrets without known patterns
• Historical repository scanning
• High-entropy secret detection

Strengths:

• Entropy detection: Find secrets without regex
• Git history: Scan entire repository history
• Verified secrets: Attempts to verify found secrets
• Active scanning: Real-time monitoring

---

GitGuardian (Commercial)

When to Use:

• Need real-time protection
• Want incident response workflow
• Require compliance reporting
• Budget for commercial solution

Strengths:

• Real-time monitoring: Instant alerts on secret commits
• Incident response: Guided remediation workflows
• Compliance: Audit trails and reporting
• Developer education: Training and awareness

---

Decision Flowcharts

Container Scanning Decision Tree

START: Need to scan container image

Q1: Budget and requirements?
  ├─ Open-source + comprehensive → Q2
  ├─ Open-source + accuracy focus → Grype + Syft
  └─ Commercial + developer UX → Snyk Container

Q2: Open-source comprehensive choice
  ├─ Need SBOM + scan in one tool? → YES: Trivy
  ├─ Need minimal false positives? → NO: Grype + Syft
  └─ Default choice → Trivy

SAST Decision Tree

START: Need static code analysis

Q1: Budget?
  ├─ Open-source → Q2
  └─ Commercial → Q3

Q2: Open-source SAST
  ├─ Need fast + customizable? → Semgrep
  ├─ Using GitLab? → GitLab SAST
  └─ Default → Semgrep

Q3: Commercial SAST
  ├─ Developer UX priority? → Snyk Code
  ├─ Enterprise quality gates? → SonarQube
  └─ Default → Snyk Code

DAST Decision Tree

START: Need dynamic application testing

Q1: Budget?
  ├─ Open-source → OWASP ZAP
  └─ Commercial → Q2

Q2: Commercial DAST needs
  ├─ CI/CD native required? → StackHawk
  ├─ Manual + automated? → Burp Suite
  └─ Default → StackHawk

---

Tool Comparison Matrices

Container Scanning Comparison

SAST Comparison

Secret Scanning Comparison

---

Recommended Combinations

Startup/Small Team

Container: Trivy (comprehensive, free)
SAST: Semgrep (fast, customizable)
DAST: OWASP ZAP (full-featured, free)
SCA: Dependabot (GitHub native, free)
Secrets: Gitleaks (fast, configurable)

Cost: $0
Setup: Low complexity

Mid-Size Company

Container: Trivy + Snyk Container (comprehensive + UX)
SAST: Semgrep + Snyk Code (coverage + developer UX)
DAST: StackHawk (CI/CD native)
SCA: Renovate (advanced automation)
Secrets: GitGuardian (real-time protection)

Cost: Moderate
Setup: Moderate complexity

Enterprise

Container: Snyk Container (unified platform)
SAST: SonarQube (quality gates + compliance)
DAST: Burp Suite Enterprise
SCA: Snyk Open Source (comprehensive)
Secrets: GitGuardian Enterprise (incident response)

Cost: High
Setup: High complexity
Benefits: Unified dashboards, compliance, support

---

Selection Checklist

Use this checklist to select appropriate tools:

Requirements:

• [ ] Budget: Open-source, commercial, enterprise?
• [ ] Languages: Which languages need scanning?
• [ ] CI/CD platform: GitHub Actions, GitLab CI, Jenkins, other?
• [ ] Team size: How many developers?
• [ ] Security maturity: Beginning, intermediate, advanced?
• [ ] Compliance: SOC2, ISO 27001, PCI-DSS requirements?

Evaluation Criteria:

• [ ] Speed: CI/CD pipeline impact (target < 5 minutes)
• [ ] Accuracy: False positive tolerance?
• [ ] Coverage: OS, languages, secrets, misconfig?
• [ ] Integration: Existing tools and workflows?
• [ ] Maintainability: Active development, community support?
• [ ] Scalability: Can handle codebase growth?

Decision:

• Container scanning: ________________
• SAST: ________________
• DAST: ________________
• SCA: ________________
• Secret scanning: ________________