Getting Developers to Fix Vulnerabilities: SLA Workflow and Escalation Playbook
Retool's new app builder is where AI-generated code ships safely
Building apps with AI is easy. Getting them to production safely is another story.
Vulnerability management fails at the handoff point. A scanner produces a finding. A security analyst triages it. A Jira ticket is opened manually, often without enough context for an engineer to act. The ticket sits in the backlog while the engineer works on features. The vulnerability ages. Repeat.
The solution is not to pressure engineers harder. It is to remove friction from the remediation path and make SLAs enforceable through process rather than personality. Engineers respond to clear acceptance criteria, reproducible test cases, and reasonable timelines. They do not respond to CVSS scores and CVE numbers without context.
This guide builds the full workflow: SLA tiers calibrated to actual exploitability (not raw CVSS), automated ticket creation from scanner webhooks, a sprint story template that gives engineers everything they need to fix and verify, an escalation matrix tied to business risk rather than security opinion, and a dashboard that measures what matters: mean time to remediation (MTTR) by severity and team.
Realistic SLA Tiers Calibrated to Exploitability
CVSS alone is a poor basis for SLAs. A CVSS 9.8 vulnerability in an internal tool behind a VPN, accessible only to authenticated administrators, poses far less risk than a CVSS 7.2 vulnerability in an internet-facing login endpoint actively targeted by ransomware groups.
Use a four-tier model with SLA windows based on exploitability context, not score alone. Critical (7-day SLA): CVSS 9.0-plus AND (in CISA KEV catalog OR EPSS score above 0.90 OR confirmed active exploitation in threat intelligence). These represent immediate operational risk. High (30-day SLA): CVSS 7.0 to 8.9 AND (internet-facing OR privileged escalation path). Medium (90-day SLA): CVSS 4.0 to 6.9 OR CVSS 7.0-plus with no network exposure. Low/Informational (next-quarter planning): CVSS below 4.0 or best-practice issues without direct exploitability.
Incorporate EPSS scores from the FIRST EPSS API into your triage workflow: GET https://api.first.org/data/v1/epss?cve=CVE-2024-XXXX. EPSS provides a probability score for exploitation within 30 days. A vulnerability with EPSS above 0.50 should trigger Critical SLA regardless of CVSS, as more than half of discovered vulnerabilities at that score level get exploited within a month.
Document the SLA tiers in a policy document that has been reviewed by legal, signed off by the CISO, and acknowledged by engineering leadership. SLAs without executive alignment are aspirational rather than enforceable.
Jira Auto-Ticket Creation via REST API from Scanner Webhooks
Most enterprise scanners (Tenable, Rapid7, Wiz, Snyk, Semgrep) support webhooks that fire when new findings are created or severity thresholds are crossed. Connect these webhooks to an automation service that calls the Jira REST API.
The Jira create issue endpoint: POST https://your-domain.atlassian.net/rest/api/3/issue. Authenticate with an API token stored as a secret in your automation platform (not hardcoded in the webhook handler).
Minimum required fields in the request body: project key, issue type (Story or Bug), summary, description, priority (mapped from your SLA tier), labels (security-finding, scanner-name, severity-tier), custom fields for CVE ID, affected component, and due date (calculated from creation date plus SLA window in days).
Set the assignee automatically based on the affected repository or service. Maintain a mapping table: repository-or-service-name to engineering-team-Jira-project-key. When the scanner webhook fires for a finding in the auth-service repository, the ticket is created in the AUTH-TEAM Jira project and assigned to that team's security champion.
Avoid creating duplicate tickets. Before creating a new issue, query the Jira API for existing open issues with matching CVE ID and component: GET /rest/api/3/search?jql=project=AUTH-TEAM AND labels=CVE-2024-XXXX AND status!=Done. Only create the ticket if no open match exists.
Briefings like this, every morning before 9am.
Threat intel, active CVEs, and campaign alerts, distilled for practitioners. 50,000+ subscribers. No noise.
Sprint Story Template for Security Fixes
The ticket format determines whether engineers engage or defer. Security tickets written in security language get deferred. Security tickets written in engineering language with clear acceptance criteria get picked up.
The template structure:
Summary: Fix [vulnerability type] in [component/library] - [CVE ID] ([SLA tier] severity, due [date]).
Background (2-3 sentences maximum): What the vulnerability is and why it matters to this specific service. Avoid generic CVE descriptions. Write it for an engineer who has never heard of this CVE.
Reproduction steps: Numbered list of exact commands or HTTP requests to reproduce the vulnerability in a development environment. If the scanner provides a PoC, include it. If not, write one.
Remediation: The specific fix required. Upgrade library X from version Y to Z. Apply the vendor patch. Replace function A with function B. Link to the vendor advisory or patch notes.
Acceptance criteria (checkboxes): Library version updated in package manifest. Scanner rescan shows finding resolved. Unit test added for the vulnerable code path. Change deployed to staging and confirmed resolved.
Verification: The security team will re-scan the component within 48 hours of ticket closure to confirm resolution. If the finding persists, the ticket will be reopened.
This template removes three common failure modes: engineers not knowing what to fix, engineers not knowing how to verify the fix, and security teams not following up on closed tickets that were not actually remediated.
Escalation Matrix
SLAs without escalation paths are soft deadlines. The escalation matrix defines what happens at each stage of an overdue finding, who is notified, and what authority they have to act.
For Critical (7-day SLA): Day 5 (T-2): Automated Jira comment and Slack DM to the assigned engineer and security champion. Day 7 (due date): If unresolved, automated Slack message to the engineering manager and security program manager. Day 10 (T+3): If still unresolved, security program manager notifies CISO and VP of Engineering. At this point the vulnerability may be escalated to a production change freeze for the affected service until remediated.
For High (30-day SLA): Day 25 (T-5): Automated reminder to engineer and security champion. Day 30: Notification to engineering manager. Day 45: CISO and VP Engineering escalation.
For Medium (90-day SLA): Day 80: Automated reminder. Day 90: Engineering manager notification only. No CISO escalation for Medium findings.
The escalation matrix must be agreed upon by engineering leadership before deployment. An escalation path that the engineering VP has not committed to will be ignored. Treat this as a business process negotiation, not a security policy imposition.
MTTR Dashboard and Vuln Exception Handling
Mean time to remediation is your primary program health metric. Track it by severity tier, by engineering team, and by vulnerability type (container image, code dependency, infrastructure misconfiguration, cloud resource). This segmentation tells you where process breakdowns are occurring, not just that they are occurring.
Build the dashboard in Jira using the built-in reporting features or export to a BI tool. Key metrics: MTTR by severity (target: Critical below 5 days, High below 25 days, Medium below 80 days), SLA breach rate per team (percentage of findings that exceeded their SLA window), reopened ticket rate (findings closed but not actually remediated), and backlog age distribution (how many open findings are in each 30-day age bucket).
Vulnerability exceptions are necessary for findings that genuinely cannot be remediated within SLA due to vendor patch unavailability, architectural constraints, or business continuity risk from the remediation itself. The exception process must include: a formal written request from the engineering team owner, a compensating control (WAF rule, network segmentation, increased monitoring), a maximum exception duration (90 days for Critical exceptions, 180 days for High), and explicit sign-off from the asset owner's VP and the CISO.
Store approved exceptions in a dedicated Jira component or a separate register. Automate exception expiry reminders. An exception that expires without renewal should automatically reopen the original finding and restart the SLA clock.
Subscribe to unlock Remediation & Mitigation steps
Free subscribers unlock full IOC lists, Sigma detection rules, remediation steps, and every daily briefing.
The bottom line
The goal of a vulnerability SLA program is not compliance theater. It is reducing the window of exploitability for real threats against real systems. Review your SLA tiers against actual exploitation data every six months. If your Critical tier is catching findings that have never been exploited in the wild, and your High tier is missing findings on the CISA KEV catalog, your thresholds need recalibration.
Frequently asked questions
How do we handle a critical vulnerability in a third-party library that has no patch available yet?
Open the exception process immediately rather than waiting for a patch. Document the compensating controls you have in place (WAF rule blocking the vulnerable code path, network segmentation isolating the affected service, enhanced logging). Set a review date for 30 days out. When a patch becomes available, the exception expires and the standard SLA clock starts from the patch release date.
What is the right way to handle duplicate CVEs across multiple scanner tools?
Deduplicate on CVE ID plus affected component. The same CVE affecting the same library in the same service is one finding regardless of how many scanners reported it. Your webhook handler should query for existing open tickets before creating a new one. Track which scanners contributed to a finding in a custom field so you know when all scanners have confirmed resolution before closing.
Should security findings go into the engineering team's existing backlog or a separate security backlog?
Into the engineering team's existing backlog. A separate security backlog gets ignored because it is outside the sprint planning and prioritization process. Security findings compete for sprint capacity alongside feature work when they are in the same backlog. This is by design: it forces explicit prioritization conversations rather than allowing security debt to accumulate in a silo.
How do we get engineering leadership to commit to the escalation matrix?
Frame the SLA program in terms of regulatory and business risk, not security posture. If your organization is subject to SOC 2, PCI DSS, or ISO 27001, show the specific control requirements that the SLA program satisfies. Quantify the cost of a breach for a Critical unpatched vulnerability using historical breach cost data. Leadership commitment is far easier when the alternative to SLA compliance is articulated in business impact terms.
What is an acceptable SLA breach rate for a mature vulnerability management program?
For Critical findings, a mature program targets below 5% breach rate. For High findings, below 15%. For Medium, below 25%. If your breach rates are above these thresholds, the problem is usually one of three things: SLA windows are unrealistically tight, engineering teams lack the capacity to address security debt alongside feature work, or the triage process is miscategorizing too many findings as higher severity than their actual risk warrants.
Sources & references
Free resources
Critical CVE Reference Card 2025–2026
25 actively exploited vulnerabilities with CVSS scores, exploit status, and patch availability. Print it, pin it, share it with your SOC team.
Ransomware Incident Response Playbook
Step-by-step 24-hour IR checklist covering detection, containment, eradication, and recovery. Built for SOC teams, IR leads, and CISOs.
Get threat intel before your inbox does.
50,000+ security professionals read Decryption Digest for early warnings on zero-days, ransomware, and nation-state campaigns. Free, daily, no spam.
Unsubscribe anytime. We never sell your data.
Founder & Cybersecurity Evangelist, Decryption Digest
Cybersecurity professional with expertise in threat intelligence, vulnerability research, and enterprise security. Covers zero-days, ransomware, and nation-state operations for 50,000+ security professionals every morning.
Win a $2,495 Black Hat pass.
Full-access to Black Hat USA 2026 in Las Vegas. Subscribe free to enter.