Building Vulnerability Exception Tracking System

---
name: building-vulnerability-exception-tracking-system
description: Use when build a vulnerability exception and risk acceptance tracking
  system with approval workflows, compensating controls documentation, and expiration
  management. Use when building a vulnerability exception and risk acceptance tracking
  system with.
domain: cybersecurity
subdomain: vulnerability-management
tags:
- vulnerability-exception
- risk-acceptance
- compensating-controls
- exception-tracking
- vulnerability-management
- governance
version: '1.0'
author: oyi77
license: Apache-2.0
nist_csf:
- ID.RA-01
- ID.RA-02
- ID.IM-02
- ID.RA-06
category: cybersecurity
---


# Building Vulnerability Exception Tracking System

## Overview

A vulnerability exception tracking system manages cases where vulnerabilities cannot be remediated within SLA timelines. It provides structured workflows for requesting exceptions, documenting compensating controls, obtaining risk acceptance approvals, and automatically expiring exceptions when their validity period ends. This ensures organizations maintain visibility into accepted risks while complying with frameworks like PCI DSS, SOC 2, and NIST CSF.


## When to Use
**Trigger phrases:**
- "building vulnerability exception tracking system"
- "Build a vulnerability exception and risk acceptance tracking system with approva"


- When deploying or configuring building vulnerability exception tracking system capabilities in your environment
- When establishing security controls aligned to compliance requirements
- When building or improving security architecture for this domain
- When conducting security assessments that require this implementation

## Prerequisites

- Python 3.9+ with `flask`, `sqlalchemy`, `requests`, `jinja2`
- PostgreSQL or SQLite database
- Email/Slack integration for approval notifications
- Vulnerability management platform API (DefectDojo, Qualys, Tenable)

## Exception Request Workflow

1. **Scope the task** — define objectives, boundaries, and success criteria
2. **Gather information** — collect all necessary data and context before proceeding
3. **Execute the core workflow** — follow the domain-specific steps methodically
4. **Validate results** — verify outputs against expected outcomes or baselines
5. **Document findings** — record results, anomalies, and recommendations
### Exception Categories
| Category | Description | Max Duration | Approver Level |
|----------|------------|-------------|----------------|
| Remediation Delay | Patch available but deployment blocked | 30 days | Team Lead + Security |
| No Fix Available | Vendor has not released a patch | 90 days | Security Director |
| Business Critical | System cannot be patched without outage | 60 days | VP Engineering + CISO |
| False Positive | Finding is not a real vulnerability | Permanent | Security Analyst |
| Compensating Control | Alternative mitigation in place | 180 days | Security Architect |

### Required Fields for Exception Request

```python
exception_schema = {
    "cve_id": "CVE-2024-XXXX",
    "finding_id": "unique-finding-reference",
    "asset_hostname": "prod-db-01.corp.local",
    "severity": "high",
    "cvss_score": 8.1,
    "category": "remediation_delay",
    "justification": "Database upgrade required before patch can be applied",
    "compensating_controls": [
        "WAF rule blocking exploit pattern deployed",
        "Network segmentation restricting access to trusted VLANs only",
        "Enhanced monitoring via Splunk alert for exploitation indicators"
    ],
    "requested_expiration": "2024-06-15",
    "requestor_email": "dbadmin@company.com",
    "approver_emails": ["security-lead@company.com", "ciso@company.com"],
    "risk_rating": "medium",
}
```

## Database Schema

```sql
CREATE TABLE vulnerability_exceptions (
    id SERIAL PRIMARY KEY,
    cve_id VARCHAR(20) NOT NULL,
    finding_id VARCHAR(100) NOT NULL,
    asset_hostname VARCHAR(255),
    severity VARCHAR(20),
    cvss_score DECIMAL(3,1),
    category VARCHAR(50) NOT NULL,
    justification TEXT NOT NULL,
    compensating_controls TEXT,
    status VARCHAR(20) DEFAULT 'pending',
    requested_by VARCHAR(255) NOT NULL,
    approved_by VARCHAR(255),
    requested_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
    approved_at TIMESTAMP,
    expires_at TIMESTAMP NOT NULL,
    expired BOOLEAN DEFAULT FALSE,
    risk_rating VARCHAR(20),
    review_notes TEXT,
    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
    updated_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);

CREATE TABLE exception_audit_log (
    id SERIAL PRIMARY KEY,
    exception_id INTEGER REFERENCES vulnerability_exceptions(id),
    action VARCHAR(50) NOT NULL,
    actor VARCHAR(255) NOT NULL,
    details TEXT,
    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);

CREATE INDEX idx_exception_status ON vulnerability_exceptions(status);
CREATE INDEX idx_exception_expires ON vulnerability_exceptions(expires_at);
CREATE INDEX idx_exception_cve ON vulnerability_exceptions(cve_id);
```

## Implementation

This section covers implementation for building vulnerability exception tracking system.

- Ensure all prerequisites are met before proceeding
- Follow the documented workflow steps in sequence
- Record results and any anomalies encountered during this phase
### Exception Request API

```python
from flask import Flask, request, jsonify
from datetime import datetime, timezone
import json

app = Flask(__name__)

@app.route("/api/exceptions", methods=["POST"])
def create_exception():
    data = request.json
    required = ["cve_id", "finding_id", "category", "justification", "expires_at", "requestor_email"]
    for field in required:
        if field not in data:
            return jsonify({"error": f"Missing required field: {field}"}), 400

    # Validate expiration does not exceed category maximum
    max_days = {"remediation_delay": 30, "no_fix": 90, "business_critical": 60,
                "false_positive": 365, "compensating_control": 180}
    # Insert into database and notify approvers
    return jsonify({"status": "pending", "id": "exc-12345"})

@app.route("/api/exceptions/<exc_id>/approve", methods=["POST"])
def approve_exception(exc_id):
    approver = request.json.get("approver_email")
    notes = request.json.get("notes", "")
    # Update status to approved, record approver and timestamp
    return jsonify({"status": "approved"})

@app.route("/api/exceptions/<exc_id>/reject", methods=["POST"])
def reject_exception(exc_id):
    reviewer = request.json.get("reviewer_email")
    reason = request.json.get("reason")
    # Update status to rejected, record reviewer and reason
    return jsonify({"status": "rejected"})
```

### Expiration Checker (Daily Cron)

```bash
# Check for expired exceptions daily
python3 scripts/process.py --check-expirations

# Generate monthly exception report
python3 scripts/process.py --report --output exception_report.json
```

## Compensating Controls Documentation

For each exception, compensating controls must address:
1. **Detection**: How will exploitation attempts be detected?
2. **Prevention**: What barriers reduce exploitation likelihood?
3. **Response**: What incident response procedures are in place?
4. **Monitoring**: What continuous monitoring ensures controls remain effective?

## When NOT to Use

- You need to test what you built (use performing-* skills)
- Task is about configuring existing systems (use configuring-* skills)
- You need to analyze the output (use analyzing-* skills)
- Task is about implementing vendor solutions (use implementing-* skills)
- You don't have infrastructure access
- Task requires compliance validation (use auditing-* skills)


## Red Flags

- Performing actions without explicit written authorization from the asset owner
- Testing against production systems without a defined scope and rules of engagement
- Sharing sensitive findings or credentials in unencrypted communications
- Failing to properly scope and contain the assessment before starting

## Verification

- All steps executed successfully against a test environment before production use
- Output documented with screenshots or logs demonstrating expected behavior
- Results validated against known-good baselines or reference implementations
- Documentation complete enough for another analyst to reproduce findings

## References

- [NIST SP 800-53 Rev 5 - CA-7 Continuous Monitoring](https://csrc.nist.gov/publications/detail/sp/800-53/rev-5/final)
- [PCI DSS v4.0 Compensating Controls](https://docs-prv.pcisecuritystandards.org/PCI%20DSS/Standard/PCI-DSS-v4_0.pdf)
- [CIS Controls v8 - Control 7.7](https://www.cisecurity.org/controls/continuous-vulnerability-management)

## Process

1. Analyze the task requirements
2. Apply domain expertise
3. Verify output quality

## Anti-Rationalization Table

| Rationalization | Reality |
|---|---|
| "We are too small to be targeted" | Automated attacks target everyone. Size does not matter. |
| "Security slows us down" | A breach slows you down 100x more. Build security in from the start. |
| "We will fix it after launch" | Vulnerabilities in production are exploited within hours. Fix before deploy. |