Tech vulnerability remediation is slowing as attack surfaces fragment

At a glance

What this is: Synack’s analysis says tech sector critical-vulnerability remediation slowed sharply in 2025 while lower-severity findings improved, with distributed architectures and AI-generated code helping keep SQL injection recurring.

Why it matters: For IAM and security teams, the key issue is that modern application and service estates turn vulnerability remediation into a governance and coordination problem across identities, APIs, and delivery pipelines.

By the numbers:

• The average time to remediate critical vulnerabilities in the tech sector grew from 74 days in 2024 to 98 days in 2025, representing a 32% slowdown.
• Tech companies produced 197 critical-severity SQL injection instances in Synack’s report.
• The tech sector logged 103 medium-severity content injection instances in the report.

Context

Critical vulnerability remediation has stopped being a simple patching exercise in many tech environments because the same weakness can surface across APIs, microservices, third-party integrations, and AI-assisted code paths. When a codebase changes between discovery and fix, the work shifts from isolated remediation to cross-team coordination, and that is where mean time to remediate starts to climb.

This matters to identity and access practitioners because modern delivery chains rely on service accounts, API credentials, delegated access, and release automation to move quickly. When the underlying application surface fragments, governance over who or what can change code, call services, or reach data becomes part of the remediation problem rather than a separate control domain.

Key questions

Q: What breaks when critical vulnerabilities are discovered in a fast-changing tech stack?

A: Remediation slows because the vulnerable code, the surrounding dependencies, and the responsible teams may all change before the fix is complete. In a fragmented stack, the issue is no longer just patching a line of code. It becomes a coordination problem across services, owners, and release cycles, which is why exposure windows stay open longer.

Q: Why do distributed APIs and microservices make SQL injection harder to remove?

A: They spread the same flaw across multiple ownership domains and data paths. A query issue may appear in an API endpoint, a shared service, or an integration introduced later, so one team cannot simply patch one application and be done. The result is slower containment, more retesting, and a higher chance that the flaw reappears elsewhere.

Q: What do security teams get wrong about content injection in AI-assisted workflows?

A: They often treat it as an AI output problem instead of an input-trust problem. The real failure is letting unsanitised external data reach prompt context in the first place. Once that happens, attackers can manipulate instructions, surface leaked context, or trigger logic errors in downstream workflows that rely on the model’s response.

Q: How should organisations measure whether vulnerability remediation is keeping up with delivery speed?

A: They should compare time to remediate against release churn, ownership changes, and the number of dependent services touched after discovery. If the fix regularly crosses team boundaries or waits for multiple change windows, the programme is lagging the pace of development. The metric should reflect operational complexity, not just closure counts.

Technical breakdown

Why distributed APIs keep SQL injection recurring

SQL injection remains a familiar flaw, but its operational shape has changed. In monolithic applications, one team could patch the vulnerable query path and close the issue. In distributed systems, the same pattern can reappear in API endpoints, shared data services, partner integrations, or AI-generated scaffolding that reaches the database layer. The technical problem is not that the vulnerability is new, but that ownership, data flow, and change velocity are now spread across multiple components and teams. That makes discovery-to-fix time longer because each dependency can alter the exploit path or the remediation plan.

Practical implication: map SQLi exposure to service ownership and data paths, not just to a single codebase.

How speed-to-ship creates content injection exposure

Content injection arises when raw external material is placed into AI prompt contexts without sanitisation. That input can come from user uploads, scraped content, or other untrusted sources that influence model behaviour. The risk is not limited to incorrect output. It can also surface leaked context, manipulated instructions, or downstream logic errors in AI-assisted workflows. This is an application-security and AI-governance problem at the same time, because the control failure sits at the boundary between data handling and model prompting. The faster teams ship, the more likely these boundaries get bypassed in the name of delivery.

Practical implication: validate and sanitise prompt inputs before they reach model context, especially in AI-assisted workflows.

Why remediation takes longer once the codebase keeps changing

A vulnerability discovered in a stable system can often be patched with limited blast radius. A vulnerability discovered after multiple release cycles is harder because the original code, the surrounding dependencies, and the responsible teams may all have changed. That turns remediation into sequencing work: identify the live instance, trace the affected assets, coordinate owners, and verify that the fix still holds after deployment. In practice, this is why vulnerability management becomes a governance discipline as much as a technical one. The longer the exposure window stays open, the more likely the fix is to require coordination across teams that no longer share a single delivery context.

Practical implication: shorten exposure windows with continuous testing and asset-to-owner correlation.

Threat narrative

Attacker objective: The attacker aims to exploit a familiar weakness across a fragmented stack so the technical issue becomes a business disruption and a slower response.

1. Entry occurs when attackers find SQL injection or content-injection paths in distributed APIs, microservices, or prompt-fed workflows.
2. Credential or data access follows when the flaw reaches database queries, shared services, or AI prompt contexts that influence downstream decisions.
3. Impact emerges as attackers manipulate outputs, access data, or force remediation work to span multiple teams and code paths.

Breaches seen in the wild

• United Nations breach 2021: Sakura Samurai used exposed Git credentials to reach 100,000+ UNEP staff records, then reported the flaw through the UN disclosure programme.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Critical vulnerability remediation is now a coordination problem, not just a patching problem. The data shows tech can improve at high, medium, and low severity while still getting worse at critical fixes. That tells us the bottleneck is no longer simple triage, but ownership across services, dependencies, and delivery teams. The governance lesson is that vulnerability management must follow the asset graph, not the ticket queue.

Distributed architecture creates a remediation delay tax. The same vulnerability class can exist in the core application, a partner API, or AI-generated code, and each location changes who has to act and how quickly. This is especially relevant where service accounts, tokens, and API credentials allow rapid machine-to-machine movement. For identity teams, the practical conclusion is that access governance and application remediation now share the same blast radius.

Content injection is the clearest signal that AI-era application security failures are being normalised. Raw external inputs reaching prompt contexts without sanitisation create a predictable manipulation path, not an exotic edge case. That is a model of governance debt: development speed accumulates risk faster than review processes can clear it. Organisations should treat prompt handling, input trust, and change control as one control family.

Continuous testing is becoming the baseline because static remediation models cannot keep pace with code churn. The longer a vulnerability persists while the codebase changes around it, the more cross-team work it requires. That makes earlier discovery a governance advantage, not just a security convenience. Security leaders should measure how quickly issues are found relative to release velocity, not only how quickly they are closed.

From our research library:

• The average time to mitigate a leaked secret is 36 hours, highlighting the operational burden of manual remediation processes, according to the 2024 State of Secrets Management Survey.
• The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to the State of Secrets in AppSec.
• Read next: Low-Code Agent Platform Security Guide

What this signals

Tech vulnerability remediation is now constrained by system fragmentation. The issue is not simply that critical flaws exist, but that distributed services, API sprawl, and AI-generated code turn each fix into a change-management exercise. For practitioners, the useful response is to bind vulnerability ownership to the asset graph and the delivery pipeline, not to a generic ticketing workflow.

Cross-asset intelligence is the right governance model for this problem. Vulnerabilities should be prioritised by how they move through APIs, services, and code owners, not only by severity score. That shift matters because remediation speed depends on coordination quality as much as technical skill.

For practitioners

• Implement continuous testing earlier in the delivery cycle Surface critical findings before multiple release changes make the fix a coordination exercise across teams and services.
• Correlate vulnerabilities to service ownership Track each finding to the exact API, microservice, data layer, or third-party integration that owns the risk so remediation is not handled as a generic ticket.
• Sanitise all prompt-bound external inputs Treat user uploads, scraped content, and external feeds as untrusted before they reach model context or AI-assisted workflows.
• Measure remediation against code churn Compare time to remediate with the number of releases or dependency changes that occur after discovery to identify where coordination is slowing closure.
• Use cross-asset intelligence for prioritisation Combine application, API, and delivery-pipeline findings into one view so critical issues are prioritised by shared exposure, not by isolated severity labels.

Key takeaways

• Critical remediation slowed in tech even while lower-severity issues improved, which points to coordination breakdowns rather than a general decline in security performance.
• Distributed APIs, microservices, third-party integrations, and AI-generated code widen the blast radius of familiar flaws like SQL injection.
• The most effective response is earlier discovery, stronger ownership mapping, and remediation tied to asset graphs instead of isolated tickets.

Key terms

• Mean Time To Remediate: Mean Time To Remediate is the average time it takes to fix an identified issue after it is detected. In security and operations, it measures how long a vulnerability, misconfiguration, access problem, or incident remains unresolved, from confirmation through containment, correction, validation, and closure.
• SQL Injection: SQL injection is a flaw where untrusted input is interpreted as part of a database query. In practice, it lets an attacker read, change, or delete data by manipulating the application’s request handling rather than by logging in with valid credentials.
• Content injection: The placement of hidden instructions inside otherwise legitimate content so that a downstream system reads them as part of its task. In agentic environments, content injection matters because the agent may treat attacker text as executable context rather than as untrusted input.
• Cross-Asset Intelligence: Cross-asset intelligence is the practice of analysing security findings across related systems, owners, and dependencies rather than treating each alert as isolated. It helps teams understand how a vulnerability moves through APIs, services, code, and identities, which is essential when remediation requires coordination.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps practitioners connect identity controls to broader security operations and remediation workflows.