Accelerate remediation without slowing developers

Mean Time To Remediate is the most important KPI of a DevSecOps program — and the most poorly measured.

Most organizations measure MTTR as the time between "ticket created" and "ticket closed". That's wrong. What that measures is the time between decision to take it on and administrative closure. Not the real resolution time.

The real MTTR is measured between "vulnerability detected by the scanning tool" and "fix merged into main". This definition captures all process frictions: triage, decision, assignment, understanding, development, review, merge. It's the only metric that reflects operational reality.

If you're a CISO or AppSec engineer, you know the pattern: you create a Jira ticket from a SAST finding, assign it to a team, and nothing happens. A month later, the ticket is still open. Six months later, still open.

Developers are not acting in bad faith. Your tickets are simply unreadable. Here's what a typical security ticket contains:

• An auto-generated title like "SQL Injection detected in UserRepository.java line 142"
• A link to the SAST tool dashboard (which the dev never opens)
• A CVSS score with no context
• No indication of the recommended fix
• No indication of real impact if left unfixed
• No relative prioritization compared to other sprint tickets

« When I get a ticket like that, my first reflex is to mark it "needs more info" and let it sleep. I don't have time to become a security expert to understand it. »

A developer in flow who gets interrupted by an out-of-context ticket takes on average 23 minutes to regain focus. That's a measured number from a UC Irvine study (Gloria Mark).

Multiply by 20 poorly-worded security tickets sent to a dev team each week, and you've mathematically wiped out a full day of productive development — per team, per week. The cumulative cost over a year is substantial.

Between detecting a vulnerability and merging its fix, there are 7 stages. Each is a source of friction.

1. 1Detection — the scanner creates a finding.
2. 2Triage — someone decides whether to fix or ignore.
3. 3Assignment — the finding becomes a ticket assigned to a team.
4. 4Understanding — the dev must grasp the problem, often by diving into an unfamiliar scan tool.
5. 5Decision — the dev assesses the fix and its feasibility.
6. 6Development — the dev writes the fix.
7. 7Review and merge — the fix is reviewed and merged.

Steps 1, 2, 3 and 4 can be fully automated and contextualized. Steps 5, 6 and 7 must remain human — but can be greatly accelerated by enriched context and a fix proposal.

A good security ticket never asks the developer to open another tool. All the information they need is in the ticket itself.

What a well-contextualized ticket contains

• The exact file and line, with a clickable link to the repo
• The vulnerable code snippet, inlined directly
• A natural-language explanation of the problem, not CVSS jargon
• The recommended fix, with an example of corrected code
• Business impact — actively exploited or not, internet-exposed or not, application criticality
• Relative priority compared to the team's other security tickets
• A link to the detecting tool for the curious — but not as the sole source of truth

Most integrations between security tools and ticketing are one-way: security creates tickets in Jira, but when the dev closes the ticket, the security tool doesn't know.

Result: security dashboards stay full of already-fixed alerts, and nobody trusts the data.

Two-way sync fixes this. When the ticket is closed on the dev side, the vulnerability is automatically re-scanned to verify it's actually fixed, and the status bubbles up to the security platform. And vice versa: if a vulnerability disappears from a scan, the associated ticket is closed automatically.

A mature remediation policy defines differentiated SLAs by severity:

• Critical actively exploited: 24h
• Critical not exploited: 7 days
• High: 30 days
• Medium: 90 days
• Low: best effort

These SLAs must be tracked in real time — not in a quarterly Excel. And they must be visible per team, so teams that hit their SLAs are recognized and those drifting are supported.

State of the art in 2026 is an AI agent that reads the ticket, generates a proposed fix, and opens a merge request for a developer to review and merge. It's not science fiction — it runs in production in several organizations.

What the agent can do

• Understand the code context around the vulnerability
• Propose a fix consistent with the project's patterns
• Open an MR with description, tests and rationale
• Iterate on code review feedback

What the agent must never do

• Merge without human review
• Modify critical code (auth, payments, crypto) without explicit validation
• Unilaterally decide on residual risk acceptance