Plantilla de Proceso de Gestión de Vulnerabilidades

Overview

Un vulnerability management process define cómo un organization descubre, triagea, prioriza, remedia y verify vulnerabilidades across su infrastructure y applications. Establece scanning schedules, severity thresholds, remediation SLAs y reporting procedures. Sin un defined process, vulnerabilidades accumulan y se vuelven exploitable attack vectors.

When to Use

• For alternatives, see Penetration Test Report Template.

• Estableciendo vulnerability management para un new organization

• Preparándote para compliance audits (SOC 2, ISO 27001, PCI-DSS)

• Estandarizando vulnerability handling across teams

• Definiendo remediation SLAs y accountability

• Seteando up automated vulnerability scanning en CI/CD

Solution

# Vulnerability Management Process — `<Organization Name>`

## Process Overview

| Field | Value |
|-------|-------|
| Organization | Example Corp |
| Process Version | 2.0 |
| Last Updated | 2026-07-05 |
| Process Owner | Security Team |
| Approved By | CISO |
| Review Cycle | Quarterly |
| Next Review | 2026-10-05 |
| Compliance Frameworks | SOC 2, ISO 27001, PCI-DSS |
| Scanning Tools | Trivy, Snyk, Nessus, GitLeaks |
| Ticketing System | Jira |

## 1. Vulnerability Discovery

### Scanning Schedule

| Asset Type | Tool | Frequency | Scope | Owner |
|------------|------|-----------|-------|-------|
| Container images | Trivy | Every build (CI) | All images | DevOps |
| Application dependencies | Snyk | Every PR + daily | All repos | Developers |
| Infrastructure (cloud) | Prowler | Weekly | All cloud accounts | Security |
| Network (hosts) | Nessus | Weekly | All subnets | Security |
| Kubernetes clusters | kube-bench | Weekly | All clusters | DevOps |
| Source code | GitLeaks + Semgrep | Every PR | All repos | Developers |
| Secrets in code | GitLeaks | Every PR + nightly | All repos | Security |
| SSL/TLS certificates | SSLyze | Daily | All endpoints | DevOps |
| DNS configuration | DNSRecon | Weekly | All domains | Security |
| Web applications | OWASP ZAP | Weekly + on release | Production URLs | Security |

### Scan Configuration

| Tool | Configuration | Threshold | Fail Build? |
|------|--------------|-----------|-------------|
| Trivy | `--severity CRITICAL,HIGH` | 0 critical, 0 high | Yes |
| Snyk | `--severity-threshold=high` | 0 high | Yes (on PR) |
| Nessus | Credential scan, full policy | All CVEs | N/A (report) |
| GitLeaks | All patterns, custom rules | 0 findings | Yes |
| Semgrep | Custom rules + default | 0 high | Yes (on PR) |
| Prowler | CIS benchmarks | All checks | N/A (report) |
| kube-bench | CIS Kubernetes benchmark | All checks | N/A (report) |

### Asset Inventory

| Asset Category | Inventory Source | Update Frequency | Owner |
|----------------|-----------------|------------------|-------|
| Cloud resources | AWS Config | Real-time | DevOps |
| Kubernetes resources | kubectl + cluster API | Real-time | DevOps |
| Container images | Container registry | On push | DevOps |
| Source code repos | GitHub API | On creation | Engineering |
| Dependencies | Lockfile analysis | On commit | Developers |
| SSL certificates | ACM + external | Daily | DevOps |
| DNS records | Route53 + external | Daily | DevOps |
| Third-party services | Manual registry | Quarterly | Security |

## 2. Vulnerability Triage

### CVSS Scoring

| CVSS Score | Severity | Color | Action |
|------------|----------|-------|--------|
| 9.0 - 10.0 | Critical | Red | Immediate remediation |
| 7.0 - 8.9 | High | Orange | Remediate within SLA |
| 4.0 - 6.9 | Medium | Yellow | Remediate within SLA |
| 0.1 - 3.9 | Low | Blue | Track, remediate opportunistically |
| 0.0 | None | Green | No action needed |

### Triage Criteria

| Factor | Question | Weight |
|--------|----------|--------|
| CVSS score | Cuál es el base CVSS score? | 40% |
| Exploitability | Hay un public exploit available? | 25% |
| Exposure | Está el affected service internet-facing? | 15% |
| Data sensitivity | Expone el vulnerability PII/PHI? | 10% |
| Business impact | Cuál es el business impact de exploitation? | 10% |

### Triage Decision Matrix

| CVSS | Public Exploit | Internet-Facing | PII Exposure | Final Severity |
|------|---------------|-----------------|--------------|----------------|
| Critical | Yes | Yes | Yes | Critical (SEV-0) |
| Critical | Yes | Yes | No | Critical (SEV-0) |
| Critical | No | Yes | Yes | High (SEV-1) |
| High | Yes | Yes | No | High (SEV-1) |
| High | No | No | No | Medium (SEV-2) |
| Medium | Yes | Yes | No | Medium (SEV-2) |
| Medium | No | No | No | Low (SEV-3) |
| Low | No | No | No | Low (SEV-4) |

### Triage Process

| Step | Action | Responsible | SLA |
|------|--------|-------------|-----|
| 1 | Scan completes y findings ingested | Automated | Immediate |
| 2 | Deduplicateá contra existing tickets | Automated | Immediate |
| 3 | Aplicá triage criteria | Security Analyst | 24 hours |
| 4 | Assigná final severity | Security Analyst | 24 hours |
| 5 | Creá remediation ticket | Automated (Jira) | Immediate |
| 6 | Assigná a asset owner | Security Analyst | 24 hours |
| 7 | Notifyá owner | Automated (Slack) | Immediate |

## 3. Remediation SLAs

### SLA by Severity

| Severity | Remediation SLA | Exception Process | Reporting |
|----------|----------------|-------------------|-----------|
| Critical (SEV-0) | 24 hours | CISO approval required | Daily hasta resolved |
| High (SEV-1) | 7 days | Manager + Security approval | Weekly |
| Medium (SEV-2) | 30 days | Manager approval | Monthly |
| Low (SEV-3) | 90 days | Track en backlog | Quarterly |
| Informational (SEV-4) | No SLA | N/A | Quarterly |

### SLA by Context

| Context | Critical | High | Medium | Low |
|---------|----------|------|--------|-----|
| Internet-facing production | 24 hours | 3 days | 14 days | 60 days |
| Internal production | 48 hours | 7 days | 30 days | 90 days |
| Staging environment | 7 days | 14 days | 60 days | 180 days |
| Development environment | 14 days | 30 days | 90 days | 180 days |
| End-of-life systems | 24 hours | 7 days | N/A | N/A |

### Remediation Methods

| Method | When to Use | Example | Verification |
|--------|-------------|---------|--------------|
| Patch | Vendor patch available | Updateá package a fixed version | Re-scan, verify version |
| Configuration change | Misconfiguration | Disableá vulnerable protocol | Re-scan, verify config |
| Code fix | Custom code vulnerability | Fixeá en source code | SAST scan, code review |
| Compensating control | No patch available | WAF rule para block exploit | Penetration test |
| Risk acceptance | Low risk, high cost to fix | Documentá y acceptá | Risk acceptance form |
| Decommission | System no longer needed | Removeá vulnerable system | Verify removal |

### Exception Process

| Step | Action | Responsible | Duration |
|------|--------|-------------|----------|
| 1 | Documentá exception request | Asset Owner | 1 day |
| 2 | Describí compensating controls | Asset Owner | 1 day |
| 3 | Specificá expiration date | Asset Owner | — |
| 4 | Security review | Security Team | 3 days |
| 5 | Risk acceptance sign-off | CISO (critical/high) o Manager (medium) | 2 days |
| 6 | Recordá exception | Security Team | 1 day |
| 7 | Trackeá exception a expiration | Security Team | Ongoing |
| 8 | Re-review at expiration | Security Team | At expiry |

## 4. Remediation Workflow

### Standard Remediation

| Step | Action | Responsible | Duration |
|------|--------|-------------|----------|
| 1 | Recibí vulnerability ticket | Asset Owner | Within SLA |
| 2 | Investigá affected component | Asset Owner | 1-4 hours |
| 3 | Identificá remediation method | Asset Owner | 1-4 hours |
| 4 | Implementá fix | Asset Owner | Per SLA |
| 5 | Testeá fix en staging | Asset Owner | 1-2 hours |
| 6 | Deployeá a production | Asset Owner | Per deployment process |
| 7 | Verifyá remediation | Security Team | 24 hours |
| 8 | Closeá ticket | Security Team | 24 hours |

### Emergency Remediation (Critical)

| Step | Action | Responsible | Duration |
|------|--------|-------------|----------|
| 1 | Recibí critical vulnerability alert | On-call Engineer | Immediate |
| 2 | Pageá security team | Automated | Immediate |
| 3 | Assessá impact | On-call + Security | 30 min |
| 4 | Implementá immediate mitigation | On-call Engineer | 1-4 hours |
| 5 | Deployeá permanent fix | Engineering Team | Within 24 hours |
| 6 | Verifyá remediation | Security Team | 24 hours |
| 7 | Post-remediation review | Security Team | 3 days |
| 8 | Updateá detection rules | Security Team | 3 days |

### Dependency Upgrade Process

| Scenario | Approach | Risk | Verification |
|----------|----------|------|--------------|
| Patch version (x.y.Z) | Auto-update en CI | Low | Corré tests |
| Minor version (x.Y.z) | Updateá después de test pass | Medium | Full test suite + staging |
| Major version (X.y.z) | Manual review + migration | High | Migration plan + full QA |
| Breaking change | Evaluá alternatives | High | Migration + penetration test |
| No patch available | Compensating control | N/A | WAF rule + monitoring |

## 5. Verification

### Verification Methods

| Method | When to Use | Tool | Pass Criteria |
|--------|-------------|------|---------------|
| Re-scan | Después de patch o config change | Original scan tool | 0 findings para target CVE |
| Version check | Después de package update | Package manager | Version >= fixed version |
| Configuration check | Después de config change | Audit script | Config matches expected state |
| Penetration test | Después de major remediation | External tester | No exploitation possible |
| Code review | Después de code fix | Senior developer | Fix addressea root cause |
| Automated test | Después de code fix | SAST/DAST | 0 findings para target rule |

### Verification Checklist

| Check | Method | Responsible | Status |
|-------|--------|-------------|--------|
| Vulnerability no longer detected | Re-scan | Security | ✅/❌ |
| Fixed version deployed | Version check | DevOps | ✅/❌ |
| No regression introduced | Test suite | Developer | ✅/❌ |
| No new vulnerabilities introduced | Full scan | Security | ✅/❌ |
| Configuration documented | Wiki update | Developer | ✅/❌ |
| Ticket updated con evidence | Jira | Developer | ✅/❌ |

## 6. Reporting and Metrics

### Vulnerability Dashboard

| Metric | Target | Current | Trend |
|--------|--------|---------|-------|
| Total open vulnerabilities | < 50 | 32 | ↓ |
| Critical vulnerabilities (open) | 0 | 0 | ✅ |
| High vulnerabilities (open) | < 5 | 3 | ↓ |
| Medium vulnerabilities (open) | < 20 | 15 | ↓ |
| Low vulnerabilities (open) | < 30 | 14 | ↓ |
| SLA compliance rate | > 95% | 97% | ✅ |
| Mean time to remediate (critical) | < 24 hours | 18 hours | ✅ |
| Mean time to remediate (high) | < 7 days | 5.2 days | ✅ |
| Exceptions active | < 10 | 4 | ✅ |
| Exceptions expiring soon | 0 | 0 | ✅ |

### Reporting Schedule

| Report | Audience | Frequency | Content |
|--------|----------|-----------|---------|
| Executive summary | C-suite | Monthly | Risk posture, trends, SLA compliance |
| Technical report | Engineering leads | Weekly | Open vulnerabilities by team, SLA status |
| Compliance report | Auditors | Quarterly | Remediation evidence, exception log |
| Board report | Board of Directors | Quarterly | High-level risk posture, major findings |
| Team scorecard | Team managers | Monthly | Team-specific remediation performance |

### Vulnerability Trends

| Month | New Findings | Remediated | Net Change | Open Total |
|-------|-------------|------------|------------|------------|
| Jan 2026 | 45 | 52 | -7 | 38 |
| Feb 2026 | 38 | 41 | -3 | 35 |
| Mar 2026 | 42 | 47 | -5 | 30 |
| Apr 2026 | 35 | 38 | -3 | 27 |
| May 2026 | 40 | 36 | +4 | 31 |
| Jun 2026 | 37 | 36 | -1 | 30 |

## 7. Integration with CI/CD

### Pipeline Security Gates

| Stage | Tool | Gate Criteria | Fail Action |
|-------|------|---------------|-------------|
| Commit | GitLeaks | 0 secrets found | Block commit |
| PR (SAST) | Semgrep | 0 high findings | Block merge |
| PR (deps) | Snyk | 0 critical/high | Block merge |
| Build (container) | Trivy | 0 critical/high | Block build |
| Build (IaC) | tfsec | 0 high findings | Block build |
| Deploy (config) | kube-bench | CIS compliance | Warn (no block) |
| Post-deploy | OWASP ZAP | 0 high findings | Alert security team |

### CI/CD Configuration

```yaml
# GitHub Actions security scanning workflow
name: Security Scans
on: [push, pull_request]

jobs:
  trivy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Build image
        run: docker build -t app:${{ github.sha }} .
      - name: Trivy scan
        uses: aquasecurity/trivy-action@master
        with:
          image-ref: app:${{ github.sha }}
          severity: CRITICAL,HIGH
          exit-code: 1

  snyk:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Snyk test
        uses: snyk/actions/node@master
        with:
          severity-threshold: high
        env:
          SNYK_TOKEN: ${{ secrets.SNYK_TOKEN }}

  gitleaks:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0
      - name: GitLeaks
        uses: gitleaks/gitleaks-action@v2
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

## Explanation

Un vulnerability management process tiene five stages: discovery, triage, remediation, verification y reporting. Cada stage tiene specific tools, criteria y responsibilities. El process corre continuously — new vulnerabilidades se discover daily a medida que new CVEs se publish y new scans corren.

Discovery usa automated scanning tools. Container images se scannean en every build con Trivy. Dependencies se checkean en every PR con Snyk. Infrastructure se scannea weekly con Nessus y Prowler. Source code se scannea para secrets con GitLeaks y para code vulnerabilities con Semgrep. El scanning schedule balancea coverage con scan cost — daily scans para high-value targets, weekly para internal infrastructure.

Triage prioriza vulnerabilidades basado en más que solo CVSS scores. Un critical vulnerability con un public exploit en un internet-facing service es más urgent que un critical vulnerability en un internal-only system con no exploit available. El triage criteria combine CVSS score, exploitability, exposure, data sensitivity y business impact en un final severity rating.

Remediation SLAs enforcean timely fixes. Critical vulnerabilidades deben remediate dentro de 24 hours. High dentro de 7 days. Medium dentro de 30 days. Low dentro de 90 days. SLAs son tighter para internet-facing production systems y looser para development environments. Exceptions requiren documented compensating controls y management approval con un expiration date.

El remediation workflow ensure que fixes se testeen antes de deployment. Un patch se apply en staging, se testea, luego se deploya a production. Emergency remediation para critical vulnerabilities sigue un expedited path con immediate mitigation followed por un permanent fix dentro de 24 hours. Dependency upgrades se categorizan por version change severity — patch versions pueden auto-updatearse, major versions requiren migration planning.

Verification confirma que el fix worked. Re-scanning con el original tool confirma que el vulnerability no se detecta más. Version checks confirman que la fixed version está deployed. Test suites confirman no regressions. Sin verification, remediation tickets pueden closed mientras el vulnerability persiste — el fix no worked o no se deployed correctamente.

Reporting provee visibility en el vulnerability posture. Executive summaries muestran risk trends para el C-suite. Technical reports muestran open vulnerabilities by team para engineering leads. Compliance reports proveen evidence para auditors. Metrics trackean SLA compliance, mean time to remediate y vulnerability trends over time.

CI/CD integration previene que vulnerabilidades lleguen a production. Security gates blockean builds con critical o high vulnerabilidades. Secret scanning blockea commits con leaked credentials. SAST blockea merges con high-severity code findings. Container scanning blockea builds con vulnerable images. Estos gates shiftean vulnerability detection left — catchean issues antes de deployment en vez de después.

## Variants

| Context | Approach | Notes |
|---------|----------|-------|
| Startup | Focus en CI/CD scanning, manual triage | Trivy + Snyk + GitLeaks |
| Enterprise | Full process con dedicated team | All tools, automated triage, SLA tracking |
| Healthcare | Addeá PHI-specific scanning | HIPAA compliance checks, PHI data discovery |
| Financial | Addeá PCI-DSS scanning | ASV scans, PCI-specific remediation SLAs |
| Cloud-native | Focus en container y IaC scanning | Trivy, tfsec, kube-bench |
| Air-gapped | Offline scanning tools | Nessus offline, local CVE database |

## What Works

1. Automatizá scanning en CI/CD — catcheá vulnerabilidades antes de deployment
2. Usá CVSS como baseline, no el only factor — context matters
3. Enforceá SLAs con reporting — lo que se measurea se hace
4. Blockeá builds on critical/high — shifteá security left
5. Verifyá remediation con re-scans — no trust, verify
6. Trackeá exceptions con expiration dates — exceptions no deberían ser permanent
7. Reporteá regularly a executives — visibility drivea investment en security

## Common Mistakes

1. Scanning pero no remediando — scan reports se quedan unread
2. No SLA enforcement — vulnerabilidades stay open indefinitely
3. CVSS-only prioritization — ignora exploitability y exposure context
4. No CI/CD gates — vulnerable code llega a production
5. No verification — fixes assumed pero no confirmed
6. Exceptions sin expiration — temporary exceptions se vuelven permanent
7. No asset inventory — no podés scan lo que no conocés

## Frequently Asked Questions

### ¿Cómo handleamos vulnerabilidades sin patch available?

Usá compensating controls. Si el vulnerability está en un library con no fix, implementá un WAF rule para block el exploit vector. Si es un configuration issue, changeá la configuration. Si es un protocol vulnerability, disableá el protocol. Documentá el compensating control, su effectiveness y un expiration date para cuando el exception se re-evaluará. Trackealo como un risk acceptance con management approval.

### ¿Cuál es la difference entre vulnerability management y patch management?

Patch management es un subset de vulnerability management. Patch management focus en apply vendor patches a software y systems. Vulnerability management es broader: include patching, pero también configuration changes, code fixes, compensating controls y risk acceptance. No all vulnerabilidades tienen patches — algunas requiren configuration changes o code fixes.

### ¿Deberíamos scanneear production o solo staging?

Both. Staging scans catchean vulnerabilidades antes de que lleguen a production. Production scans catchean vulnerabilidades que se missed o se introduced después de deployment (e.g., un new CVE published para un already-deployed dependency). Production scans deberían ser non-intrusive (credential scans, no exploit scans). Usá staging para intrusive testing (penetration tests, DAST scans).

### ¿Cómo priorizamos cuando tenemos hundreds de vulnerabilidades?

Empezá con critical y high severity vulnerabilidades en internet-facing systems. Estos son los most likely de ser exploited. Next, addresseá vulnerabilidades con public exploits regardless de severity. Luego, worked through medium severity by asset importance. Low severity vulnerabilidades pueden batchearse y addressearse durante maintenance windows. Usá el triage criteria para rank within cada severity level.

### ¿Cómo handleamos false positives?

Documentá el false positive con evidence (por qué es false positive, qué se verified). Markeá el finding como false positive en el scanning tool para prevenir que reaparezca. Si el same false positive recurre, tuneá el scanner rules para excluirlo. Trackeá false positive rates per tool — si un tool tiene un high false positive rate (> 10%), considerá reemplazarlo o adjusting su configuration.