Security6 min read

Vulnerability Management

Vulnerability management from detection to remediation - how to effectively prioritize, track, and fix security issues in your applications.

Ing. Gleb Kushnir, founder · Updated

What is Vulnerability Management?

Vulnerability Management is a systematic process of identifying, assessing, prioritizing, and remediating security vulnerabilities. It is not just about running scanners - it is about the entire lifecycle from finding a problem to verifying its fix. The key is having a central place where you track all findings and can efficiently work on resolving them.

Vulnerability Lifecycle

Vulnerability Lifecycle

1. Discovery

Finding vulnerabilities using automated tools

  • SAST scanners (Semgrep, SonarQube)
  • SCA tools (Snyk, Dependabot)
  • DAST tools (ZAP by Checkmarx, formerly OWASP ZAP)
  • Container scanning (Trivy)
  • Secret detection (Gitleaks)

2. Triage

Assessing the severity and relevance of findings

  • Is it a real issue or a false positive?
  • What is the severity (CVSS score)?
  • Is the vulnerability exploitable in our context?
  • Assigning a CWE category

3. Prioritization

Determining the order of resolution based on risk

  • System criticality (production vs dev)
  • Likelihood of exploitation (EPSS) and presence in the CISA KEV catalog
  • Business impact
  • Ease of remediation

4. Remediation

Eliminating or mitigating the vulnerability

  • Code fix
  • Dependency update
  • Configuration change
  • Compensating control (WAF rule)

5. Verification

Confirming that the fix works

  • Re-scan after the fix
  • Penetration testing
  • Code review
  • Closing the ticket

DefectDojo - Vulnerability Management Platform

DefectDojo is an open-source platform for managing security findings. It integrates with many scanning tools and provides a central place for tracking all vulnerabilities.

Hierarchy in DefectDojo

  • Product Type: Highest level - e.g., "Microservices Application"
  • Product: Specific application/service - e.g., "Payment Service"
  • Engagement: Testing point in time - e.g., "Release v2.1.0"
  • Test: Type of test - e.g., "SAST Scan", "Dependency Check"
  • Finding: Specific vulnerability found

Since version 3.0, the DefectDojo Pro UI labels Product Type as Organization and Product as Asset. API v2 endpoint and field names are unchanged, so existing automation keeps working (DefectDojo documentation).

Importing scan results into DefectDojo

The /api/v2/import-scan/ endpoint does not take a product ID. It expects either an engagement ID (engagement) or the combination product_name + engagement_name. With auto_create_context, DefectDojo creates a missing engagement itself (ImportScanSerializer).

# GitLab CI - automatic upload to DefectDojo upload_to_defectdojo: stage: report image: python:3.13 script: - pip install requests - | python << 'EOF' import requests import json import os DEFECTDOJO_URL = os.environ['DEFECTDOJO_URL'] API_KEY = os.environ['DEFECTDOJO_API_KEY'] PRODUCT_NAME = os.environ['DEFECTDOJO_PRODUCT_NAME'] headers = { 'Authorization': f'Token {API_KEY}', } # Upload Semgrep results with open('semgrep-results.json', 'rb') as f: response = requests.post( f'{DEFECTDOJO_URL}/api/v2/import-scan/', headers=headers, data={ 'product_name': PRODUCT_NAME, 'auto_create_context': 'true', 'engagement_name': f'CI-{os.environ["CI_PIPELINE_ID"]}', 'scan_type': 'Semgrep JSON Report', 'active': 'true', 'verified': 'false', 'minimum_severity': 'Info', }, files={'file': f} ) print(f'Semgrep upload: {response.status_code}') response.raise_for_status() # Upload Trivy results with open('trivy-results.json', 'rb') as f: response = requests.post( f'{DEFECTDOJO_URL}/api/v2/import-scan/', headers=headers, data={ 'product_name': PRODUCT_NAME, 'auto_create_context': 'true', 'engagement_name': f'CI-{os.environ["CI_PIPELINE_ID"]}', 'scan_type': 'Trivy Scan', 'active': 'true', }, files={'file': f} ) print(f'Trivy upload: {response.status_code}') response.raise_for_status() EOF dependencies: - semgrep_scan - trivy_scan

CWE - Common Weakness Enumeration

CWE is a standardized list of security weaknesses in software and hardware. Each vulnerability has an assigned CWE ID that precisely identifies the type of problem. In MITRE's 2025 CWE Top 25, XSS (CWE-79) and SQL Injection (CWE-89) hold the first two places.

CWE Category Examples

  • CWE-89: SQL Injection
  • CWE-79: Cross-site Scripting (XSS)
  • CWE-798: Use of Hard-coded Credentials
  • CWE-22: Path Traversal
  • CWE-918: Server-Side Request Forgery (SSRF)
  • CWE-502: Deserialization of Untrusted Data

CWE vs OWASP Top 10

OWASP Top 10 are broad categories. CWEs are specific types of vulnerabilities that fall into these categories. For example, CWE-89 (SQL Injection) and CWE-79 (XSS) both fall under A05:2025 Injection in the current OWASP Top 10:2025.

Vulnerability Prioritization

CVSS - Common Vulnerability Scoring System

A standard metric for assessing vulnerability severity on a scale of 0-10. The current version is CVSS v4.0 from FIRST (released November 2023). The qualitative scale is the same as in version 3.1:

  • 0.0: None
  • 0.1 - 3.9: Low
  • 4.0 - 6.9: Medium
  • 7.0 - 8.9: High
  • 9.0 - 10.0: Critical

CVSS v4.0 labels which metric groups a score includes: CVSS-B (Base only), CVSS-BT (Base + Threat), CVSS-BE and CVSS-BTE (including Environmental). A Base score alone describes severity, not the risk in your environment.

Watch where the score comes from: since 15 April 2026, NIST prioritizes NVD enrichment only for CVEs in the KEV catalog, software used by the US federal government and critical software under EO 14028. Other CVEs are labelled "Lowest Priority - not scheduled for immediate enrichment", and NIST no longer routinely adds its own score when the CNA has provided one (NIST). Plan to rely on CNA or vendor scores and expect many CVEs in NVD to lack enrichment.

EPSS - Exploit Prediction Scoring System

EPSS from FIRST estimates the probability that a published CVE will be exploited in the wild over the next 30 days. Scores are recalculated daily and help prioritize real-world risks.

CISA KEV - Known Exploited Vulnerabilities

CISA's KEV catalog lists vulnerabilities that have a CVE ID, reliable evidence of active exploitation and a clear remediation action. A KEV entry goes to the front of the queue regardless of CVSS. Directive BOD 26-04 of 10 June 2026 replaced BOD 22-01 and sets deadlines for US federal agencies based on asset exposure, KEV status, exploit automation and technical impact (informed by SSVC). The shortest deadline is 3 days. It is not binding outside the US federal government, but it is a useful benchmark.

# Prioritization example for findings Priority 1 (Fix ASAP): - CVSS >= 9.0 - CVE in CISA KEV catalog - EPSS > 0.5 (50% exploit probability) - Production system - Internet-facing Priority 2 (Fix this sprint): - CVSS 7.0 - 8.9 - Any EPSS - Production system Priority 3 (Fix next sprint): - CVSS 4.0 - 6.9 - Production system Priority 4 (Backlog): - CVSS < 4.0 - Non-production - False positives candidate

Dealing with False Positives

Not every finding is a real problem. Security scanners often generate false positives. It is important to correctly identify and mark them so they do not burden further analysis.

How to Avoid False Positive Overload

  • Configure scanners for your stack (ignore irrelevant rules)
  • Use baselines - compare with previous scans
  • Mark false positives in DefectDojo
  • Create exceptions for known false positives
  • Regular review and cleanup of old findings

Vulnerability Management Best Practices

Process

  • Define SLAs for remediation by severity (e.g. Critical=24h, High=7d; for comparison, BOD 26-04 gives 3 days for the riskiest KEV vulnerabilities)
  • Automatically import scan results into a central platform
  • Regular triage meetings (weekly)
  • Track metrics (MTTR, open findings count, trend)
  • Report to management (monthly security posture report)

Developer Education

  • Use findings as learning material
  • Show developers what SQL injection looks like in their code
  • Security workshops focused on the most common issues
  • Share CWE documentation
  • The goal is fewer new vulnerabilities, not just fixing old ones

What NOT to Do

  • Ignore findings because "there is no time"
  • Mark everything as a false positive
  • Have hundreds of unresolved findings (alert fatigue)
  • Fix only critical issues and ignore the rest
  • Have no metrics or reporting

Sources

  1. FIRST: CVSS v4.0 Specification Document (June 2024)
  2. FIRST: Exploit Prediction Scoring System (EPSS) (October 2026)
  3. CISA: Known Exploited Vulnerabilities Catalog (June 2026)
  4. CISA: BOD 26-04: Prioritizing Security Updates Based on Risk (June 2026)
  5. NIST: NIST Updates NVD Operations to Address Record CVE Growth (April 2026)
  6. MITRE: 2025 CWE Top 25 Most Dangerous Software Weaknesses (December 2025)
  7. OWASP: A05:2025 Injection (November 2025)
  8. DefectDojo: Asset Hierarchy (Pro) (October 2026)
  9. DefectDojo (GitHub): dojo/api_v2/serializers.py (October 2026)
  10. ZAP: ZAP has joined forces with Checkmarx (September 2024)

More on this topic

Want this handled without building your own DevOps team?

Our four-person DevOps team runs your platform for a fixed monthly price.

Or write to info@devsecops.cz. We process your data under our privacy policy.