Vuln Ops Playbook

A reusable pattern for automating the operational layer of vulnerability management. Covers reporting, metrics, triage routing, exception tracking, and program hygiene. Keeps human judgment where it belongs and automates the memory.

Treat the issue tracker as the system of record and automate everything around it. The scanner files each finding as an issue. Reporting, metrics, routing, and exceptions all read from and write back to those issues on a schedule. People make the decisions that require judgment. The system handles the mechanical work and, more importantly, the memory.

The memory part matters most. Programs fail less because people cannot fix vulnerabilities and more because no one remembers which deadline is approaching, who owns an unowned finding, or which exception is about to lapse.

A scheduled job reads the live issue set and produces the same status summary a human would write each week: active count, severity breakdown, deadlines approaching and breached, and recognition for work completed. The job drafts the message and a person approves it before it sends.

One rule prevents the most common error: credit completed work since the last report, not since the start of the month, so a skipped week never double-counts.

Report structure:

• Total active vulnerabilities by severity (Critical, High, Medium, Low)
• SLA status: breached count, approaching deadline count, on-track count
• Fixes completed since the last report (not since start of month)
• End-of-life / end-of-support items tracked separately
• Kudos for engineers and teams who completed remediations
• Any new intake since last report

Operational rules:

• Draft the report automatically; a human approves before sending
• Always calculate "fixes since last report" by comparing against the last post date, not a calendar boundary
• Include a direct link to the filtered issue tracker view for every category mentioned
• When the report runs on a non-standard day (holiday, skip week), adjust the lookback window automatically

Trend reporting usually stalls on the belief that you must start collecting snapshots and wait months. You do not. Open versus closed, inflow versus outflow, time to remediate, and deadline compliance can all be reconstructed from the create and close timestamps already attached to every issue. The full history is available the day you start.

Available from day one:

• Open vs. closed over time (weekly or monthly buckets)
• Inflow vs. outflow rate: are we keeping pace?
• Mean and median time to remediate by severity
• SLA compliance rate (percentage resolved within deadline)
• Aging distribution: how many findings are 30, 60, 90+ days old

Implementation notes: Query the issue tracker for all issues with a vulnerability label/tag. Use created_at and closed_at timestamps to reconstruct any historical window. Store nothing new. The data already exists; you are just querying it differently.

Findings that the scanner cannot map to an owner pile up in a default queue. Resolve them using the code-ownership file the engineering org already maintains, narrowed to the person who actually commits to the affected path.

Routing logic:

1. Read the finding's affected file path or package name
2. Look up the path in the code-ownership file (CODEOWNERS or equivalent)
3. If a single owner is clear, propose them as the assignee
4. If ownership is ambiguous, route to the team's manager and let them delegate
5. Never assign a random member of a team just to clear the queue

Two guardrails: Route only on strong signal. If the mapping is ambiguous, say so and escalate. Silence with a flag beats a confident wrong answer that people learn to ignore.

When a finding breaches its deadline without being fixed, the choice is binary: fix it now or formally accept the risk for a bounded window. Automating the creation of that exception record forces the decision into the open.

Exception workflow:

1. Finding passes its SLA deadline without resolution
2. System automatically creates an exception request record
3. Record includes: finding details, severity, original deadline, days overdue, affected system
4. Exception requires human approval following the organization's approval matrix
5. Approved exceptions get a bounded window (30, 60, or 90 days) with an expiration date
6. System tracks the expiration and surfaces upcoming lapses in the weekly report

The line: Creating the exception record is mechanical and safe to automate. Approving the risk is a human decision that belongs to someone with the authority to make it. Never let automation grant itself permission to extend deadlines.

The register stays trustworthy only if it cleans up after itself.

• Retire exceptions when their underlying finding is canceled or fixed
• Announce cancellations: a decision to not fix something is a risk decision that someone should see
• Deduplicate findings that appear across multiple scans
• Flag findings whose linked issue was closed without a fix (closed-not-resolved)
• Surface findings approaching their deadline 7 days before breach

Anything that puts a person's name on a finding or moves work between teams starts as a suggestion a human approves. Flagging is automatic; commitment is reviewed until the logic earns trust.

The system proposes an owner when the evidence is clear and stays silent when it is not. Silence with a flag beats a confident wrong answer that people learn to ignore.

Automation can open a record, set a reminder, and route it. It should not grant itself authority it does not have. Creating a record and approving a risk are two different actions with two different permission levels.

Deduplicate, retire stale items, and surface decisions. A register no one trusts is worse than no register. Every automated change includes a reason. Every quiet decision gets surfaced.

This playbook is tool-agnostic. It assumes only that findings become trackable items in an issue tracker, each item has an owner (or lacks one), a severity, and a deadline, the issue tracker exposes an API or query interface, and a chat tool exists for report distribution and notifications.

• Weekly: Generate and send the status report (human-approved)
• Daily: Route orphaned findings, create breach exception records, propose owners, surface cancellations
• On-demand: Reconstruct metrics for any historical window

Replace the tool names with your own. The patterns stay the same whether your tracker is Linear, Jira, GitHub Issues, or a spreadsheet. The reporting channel can be Slack, Teams, email, or any destination that accepts formatted text. The code-ownership source can be a CODEOWNERS file, a service catalog, or a team directory.

• Scanner configuration or tuning
• Vulnerability remediation guidance
• Risk scoring models beyond SLA compliance
• Compliance framework mapping (SOC 2, ISO 27001, etc.)

This playbook covers the operational layer between the scanner and the humans who fix things. It assumes the scanner is already running and the remediation knowledge already exists within the engineering team.