Remediation and SLAs
Finding a vuln is the easy half. Closing it and proving it closed is the program.
What you will learn
- -Set remediation SLAs tied to risk tiers and hold to them
- -Reach for compensating controls when a patch is not available
- -Track every finding to a verified close instead of a checkbox
A finding is worthless until it is closed. Plenty of programs are excellent at generating tickets and terrible at retiring them, so the backlog grows and grows until a vuln from eighteen months ago turns up in an writeup with your name near it. The scan is the cheap part. The work that matters starts after it.
SLAs turn a finding into a task with a deadline
A vuln with no due date competes with every other priority and loses. Assign a remediation window by tier and measure against it.
- Critical or KEV-listed: 7 days, dropping to 24 to 48 hours for an actively exploited internet-facing bug.
- High: 30 days.
- Medium: 90 days.
- Low: 180 days or a documented, signed acceptance.
The exact numbers matter less than the fact that you picked them, wrote them down, and report who is past due every week. An nobody reports on is a suggestion.
Patch when you can, control when you cannot
Patching is the default and the cleanest fix, because it removes the cause. Sometimes you cannot. A vendor will not certify the app on the patched runtime, the box is a legacy nobody dares reboot, or the fix is three weeks out and the is public today. That is when compensating buy time.
- A rule or that blocks the specific exploit path.
- segmentation so the vulnerable is unreachable from where an attacker would sit.
- Disabling the affected feature or service outright until the patch lands.
A compensating control lowers risk. It does not remove the vuln, so keep the ticket open and flagged as mitigated, not fixed. Quietly closing a mitigated finding is how you forget it exists right up until the control gets rolled back.
Verify the close, do not trust it
"Resolved" in Jira is a status field, not evidence. Patches fail to apply, rolled back by a config-management run, or land on the wrong host in a rush. Confirm every fix with a rescan targeted at that host and that finding, and close only when the vuln is genuinely gone.
$nmap -p 445 --script smb-vuln-ms17-010 target$nessuscli scan --targets target --policy 'auth-single' --plugin 90510Verifying some fixes means re-running the exploit or an intrusive check against the host. Do that only inside authorized , and rehearse the destructive checks in a lab first, on a Metasploitable or DVWA VM, so you learn which ones can crash the target before you point them at a production the business depends on.
Risk acceptance is a decision, not a silence
Sometimes the answer really is "we are going to live with this one." Fine, but make it explicit: time-boxed, documented, and signed by the owner who carries the risk, not silently skipped by whoever was assigned the ticket. An accepted risk gets a review date on the calendar. A forgotten one gets you a phone call at 2 a.m.
A patch ticket is marked resolved by the server team. What actually closes the vulnerability in your program?