DevSecOps Practice Hub

Vulnerability Management

Aggregate findings from all scanners, prioritise by real risk and drive them to closure with SLAs.

IntermediateVulnerability ManagementOperationsGovernance

Where it fits in the lifecycle

  1. Plan
  2. Code
  3. Build
  4. Test
  5. Release
  6. Deploy
  7. Operate
  8. Monitor
  • Operate Runtime security, secrets rotation and configuration reconciliation.
  • Monitor Detection engineering, SIEM, compliance evidence and incident response.

Overview

Scanners produce findings; vulnerability management produces outcomes. It deduplicates across tools, assigns ownership, prioritises with exploitability and exposure data, and tracks time to remediation.

Why it matters

Detection without a closure process produces a growing backlog and no risk reduction.

How it works

  1. 01Findings from all scanners are normalised into one system.
  2. 02Duplicates are merged by component and asset.
  3. 03Priority combines severity, exploit availability (KEV/EPSS) and asset exposure.
  4. 04SLAs and dashboards track ageing and closure rates.

Common tools

DefectDojoTrivyProwlerGitLabKubernetesAWS

Implementation examples

bashPush scan results to a tracker
curl -sS -X POST "$DD_URL/api/v2/import-scan/" \  -H "Authorization: Token $DD_TOKEN" \  -F "scan_type=Trivy Scan" \  -F "engagement=$ENGAGEMENT_ID" \  -F "file=@trivy.json"
Centralising results is what makes deduplication and SLA tracking possible.

Best practices

  • Prioritise with exploitability data, not CVSS alone.
  • Track ageing, not just open counts.
  • Assign every asset an owner.

Common mistakes

  • Measuring scan coverage instead of remediation throughput.

Hands-on labs