Patch & Update Tracker
A living record of known application and dependency vulnerabilities, patch status, and remediation deadlines across owned software.
I. Overview
%%{init: { 'theme': 'base', 'themeVariables': { 'edgeLabelBackground': '#fff' }}}%%
flowchart LR
A["Patches applied reactively,\nonly after exploitation or audits"] -- "Need for proactive,\ndeadline-driven remediation" --> B["Formal Patch &\nUpdate Tracker"]
style A fill:#f9f9f9,stroke:#333,stroke-width:3px
style B fill:#e1f5fe,stroke:#01579b,stroke-width:3px
Definition: A Patch & Update Tracker is the document that inventories every application, framework, and third-party library a team owns, alongside the patches or version updates available for each, their severity, and the deadline by which they must be applied.
Features:
( Ownership ) Maintained by the AppSec team in coordination with the engineering teams that own each codebase.
( Risk Rationale ) Exists because unpatched software — not novel zero-days — is the vulnerability class attackers exploit most reliably.
( Reactive Failure Mode ) Without a tracker, patching becomes reactive, with fixes shipping only after an incident or an external scan flags a known CVE (Common Vulnerabilities and Exposures).
( Prevents Neglect ) Surfaces issues that would otherwise sit unaddressed for months.
II. Structure & Process
sequenceDiagram
participant SCA as "SCA / Vulnerability Scanner"
participant AppSec as "AppSec Team"
participant Eng as "Owning Engineering Team"
participant Lead as "AppSec Lead"
SCA->>AppSec: "Report new CVE affecting a dependency"
AppSec->>AppSec: "Triage severity and assign SLA deadline"
AppSec->>Eng: "Log entry and notify owning team"
Eng->>Eng: "Apply patch or compensating control"
Eng->>AppSec: "Submit for verification"
AppSec->>Lead: "Escalate any SLA breaches"
| Field | Description |
|---|---|
| Component | Application, service, framework, or library affected, with current version |
| Vulnerability / CVE ID | Identifier of the known weakness, sourced from vendor advisories, NVD, or an SCA tool |
| Severity | Risk rating, typically CVSS score plus exploitability context (e.g. actively exploited in the wild) |
| Patched Version | Version that resolves the issue |
| Remediation Deadline | SLA-driven date by which the patch must be applied, based on severity |
| Status | Open, Scheduled, In Progress, Verified, or Risk Accepted |
| Owning Team | Engineering team responsible for applying and validating the patch |
| Compensating Control | Interim mitigation (WAF rule, feature flag, network restriction) if the patch cannot be applied immediately |
New entries are logged continuously as scanners and vendor advisories surface issues; the tracker itself is reviewed weekly by the AppSec team and audited monthly for SLA compliance.
III. Vulnerabilities & Security Measures
| Severity | Typical SLA | Compensating Control While Open |
|---|---|---|
| Critical (actively exploited) | 24-72 hours | Emergency WAF rule, feature flag, or network isolation |
| High | 1-2 weeks | Scoped access restriction, enhanced monitoring |
| Medium / Low | Next scheduled release cycle | Standard monitoring, no interim control required |
The SLA clock is the entire point of the tracker — a critical finding sitting in an Open status with no deadline is functionally the same as an untracked vulnerability. The harder discipline is enforcing the compensating-control requirement: a team that cannot patch within SLA but also skips the interim mitigation is choosing to carry unmanaged risk, not managed risk, even if the tracker entry looks the same either way.
Related: Static Code Analysis Log, Security Misconfiguration Log
Last updated 18 Aug 2026, 00:00 UTC.