SECURITY OPERATIONS

Vulnerability Management

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

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 (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)
  • Exploit availability (EPSS score)
  • 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

Importing scan results into DefectDojo

# GitLab CI - automatic upload to DefectDojo upload_to_defectdojo: stage: report image: python:3.11 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_ID = os.environ['DEFECTDOJO_PRODUCT_ID'] 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': PRODUCT_ID, '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}') # 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': PRODUCT_ID, '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}') 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.

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 the OWASP "Injection" category.

Vulnerability Prioritization

CVSS - Common Vulnerability Scoring System

A standard metric for assessing vulnerability severity on a scale of 0-10.

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

EPSS - Exploit Prediction Scoring System

The probability that a vulnerability will be actively exploited in the next 30 days. It helps prioritize real-world risks.

# Prioritization example for findings Priority 1 (Fix ASAP): - CVSS >= 9.0 - 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 (Critical=24h, High=7d, etc.)
  • 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