Vulnerability backlog burn-down for audit is a time-boxed close, not a promise to own every CVE forever. Auditors sample Critical and High findings inside the observation window. A thousand-item board with no age-out and no exception register is how CC7.1 looks designed but not operated. The engagement we run is: pick the in-scope assets, freeze a scope of Critical/High, burn them down or except them with owners, and leave a loop that can run next period.
CISA's Known Exploited Vulnerabilities catalog is a public prioritization input (CISA KEV). NIST SP 800-53 Rev. 5 RA-5 and SI-2 describe monitoring and flaw remediation (NIST SP 800-53 Rev. 5). None of those documents say "hire a firm to be your vulnerability management department for life." They say identify, treat, and evidence.
Rutagon builds the burn-down and the evidence join. We do not operate a SOC. We do not claim Rutagon holds a SOC 2 report.
Vulnerability Backlog Burn-Down for Audit: Fixed Scope
Open-ended "we'll get to High in 30 days forever" without coverage reconciliation is how the board grows. A burn-down for audit has a written scope:
- In-scope systems (the SOC 2 boundary, not every laptop)
- Severities (usually Critical + High + KEV regardless of score)
- A start snapshot date
- A target date before the window closes
- Allowed exits: patched and retested, or excepted with owner and expiry
Everything else stays on the product backlog. We will not pretend a 4,000-item Dependabot noise pile is the audit scope.
def burn_down_scope(findings, boundary, start):
return [
f for f in findings
if f.asset in boundary
and f.first_seen <= start
and (f.severity in {"CRITICAL", "HIGH"} or f.cve in kev)
and not f.already_excepted
]
The start snapshot is sealed. New findings after the start date enter the next period's loop, not this burn-down — unless they are KEV/Critical on an in-scope asset, in which case they join immediately. That rule is written down so the auditor is not told two stories.
This is the action layer on top of SOC 2 CC7.1 vulnerability management evidence and KEV/EPSS prioritization. Dependabot/Trivy triage feeds the same board. Capability: security automation.
How We Burn Without Heroics
- Reconcile coverage. If the scanner never saw the in-scope ECS cluster, the burn-down is incomplete. Fix coverage first.
- Deduplicate. Same CVE on the same image across three tools is one ticket.
- Patch or except. Excepts require owner, rationale, expiry, compensating control. "Won't fix" without expiry is an open finding.
- Retest. Closure is a later scan, not a developer comment.
- Seal. Period artifact: open at start, closed, excepted, still-open (those are the finding).
We do not publish exploit details. Findings stay at CVE and asset. ITAR and common sense.
If the window is already late, we do not invent history. We burn what is open, seal the remainder as dated exceptions or accepted gaps, and start the standing loop so the next window is not another fire drill. See SOC 2 Type 1 vs Type 2 evidence.
What We Will Not Own
We will not take page-one on-call for your vuln scanner after the sprint. We will not replace your GRC platform. We will not quietly lower severities to make the chart pretty. Severity mapping changes are a versioned policy.
A Head of GRC who wants "someone to own SLAs" needs a standing function — FTE or a later retainer — not a burn-down. The burn-down is how you survive this window and prove the loop. Hire a compliance automation engineer if you want that function staffed.
Diagnostic
Bring the scanner export and the system boundary. We mark in-scope Critical/High, coverage holes, and a close date. You leave with a ticket list, not a maturity model.
Container images need a rebuild, not a "we patched the running task" comment. A finding on a digest that is still the latest tag in the cluster is not closed. We tie the ticket to a new digest and a deploy, then the retest. Host findings (SSM patch, AMI bake) follow the same rule: the next scan must see the new baseline.
Transitive dependency noise is why we freeze scope. If the burn-down includes every Dependabot Medium on a docs site, Criticals on the API image will not move. The GRC champion and the CTO agree the boundary in writing on day one. That writing is part of the evidence: we intended this scope, we completed it.
Infrastructure findings (open security groups, public buckets, missing encryption) are in-scope if the boundary says they are. They often live in Security Hub rather than the CVE scanner. We pull both into the same burn-down board so the auditor does not get "vulns are clean" while Config is red. The join is still first-seen, ticket, close or except, retest.
Ownership is named per asset class: image owners for container CVEs, platform for AMI/SSM, product for application dependencies. A board with every ticket assigned to "security@" does not burn down. We set the assignee from the CMDB or from CODEOWNERS, then we escalate unassigned Criticals daily during the sprint. After the sprint, that assignment rule stays in the loop.
If a Critical cannot close because a vendor is silent, the except is the honest exit. We do not leave it unlabeled in a 200-item "later" column. Later is how Type II samples a 90-day-old Critical and writes the finding. The except expiry becomes the next sprint's first ticket if the vendor is still silent.
Ask us what your GRC platform isn't covering →
907-841-8407 · contact@rutagon.com
Frequently Asked Questions
Is vulnerability backlog burn-down for audit the same as managed vuln management?
No. Managed VM is ongoing ownership. A burn-down is a fixed-scope close plus a loop you can run. Do not buy the first if you need the second this quarter.
What if we cannot patch a vendor appliance?
Except it with an owner, a vendor ticket, a compensating control (network path, WAF), and an expiry. Then follow the vendor. Do not hide it by closing the finding.
Do Lows and Mediums matter?
For this engagement, only if they are KEV or you wrote them into scope. Otherwise they stay on the product pile so Critical/High actually move.
Can we use EPSS to drop a High?
EPSS informs priority inside the scope. It does not delete a High the policy said you would treat. Change the policy in the open if you want that.
Does Rutagon certify the backlog is clean?
No. We close or except the scoped items and leave artifacts. Your auditor samples the period.