Reactive AppSec is draining developer capacity and delaying fixes

At a glance

What this is: Kusari’s research says reactive AppSec is consuming developer time, with late-stage checks and incident response creating a productivity tax that slows remediation.

Why it matters: For IAM, NHI, and security teams, the lesson is that controls added after code moves downstream create friction, while workflow-native governance is more likely to be adopted and sustained.

By the numbers:

• Teams that assess security on every pull request report 40% fewer monthly vulnerabilities than those that check only at release.

Context

AppSec becomes inefficient when risk is identified after code has already moved through the main delivery path. Late-stage detection creates rework, slows fixes, and shifts security from a shared engineering function into an interruption that developers have to absorb. The same pattern shows up in software supply chain security and AI-assisted development when controls are bolted on after implementation instead of inside the workflow.

That matters for identity-governed environments because modern software delivery depends on credentials, service accounts, tokens, and pipeline permissions that are hard to review once the change has shipped. When security checks happen in pull requests and CI pipelines, ownership is clearer and remediation can happen before the change becomes operational debt. Kusari’s findings are typical of organisations still treating AppSec as a gate rather than a lifecycle control.

Key questions

Q: What breaks when AppSec checks happen only at release time?

A: Release-only AppSec breaks down because the people closest to the change lose context before the issue is found. Ownership becomes unclear, fixes take longer, and security work turns into interruption instead of part of delivery. The practical consequence is slower remediation and more friction for developers and security teams alike.

Q: Why do pull-request security checks reduce vulnerability volume?

A: Pull-request checks reduce vulnerability volume because they catch issues while the code is still being actively edited and understood. That shortens the path from finding to fix, reduces coordination overhead, and prevents risky changes from moving deeper into the pipeline. The article’s reported 40% difference reflects that workflow timing advantage.

Q: What do security teams get wrong about AppSec tool placement?

A: The common mistake is treating AppSec as a separate review layer instead of a control embedded in the delivery workflow. When tools sit outside pull requests and CI pipelines, they create extra handoffs and more queues. The result is not stronger governance but more friction and slower response.

Q: How should development and security teams share ownership of fixes?

A: Teams should assign remediation ownership at the point where code changes are approved, not after a release problem appears. Security can define policy and risk thresholds, but development needs clear responsibility for fixing the code path. Shared ownership works when the workflow makes the handoff visible and measurable.

Technical breakdown

Why late-stage AppSec creates rework

Reactive AppSec pushes discovery to release, audit, or production, which means the people who can fix the issue are often no longer looking at the same code context. Defects then require reconstruction of intent, ownership, and dependency impact before remediation can even begin. That delay turns security findings into queue items instead of engineering tasks. In practice, the longer a finding sits outside the development workflow, the more expensive it becomes to explain, triage, and resolve.

Practical implication: move detection upstream so the developer who introduced the change can act while context is still fresh.

Pull-request checks and CI pipeline controls

Pull-request scanning and CI enforcement work because they attach security decisions to the same event that changes code, build artefacts, and dependencies. That timing matters more than the tool category. A control that fires before merge can block risky changes while the author still has the code open, while the same control at release stage only produces a backlog. This is also where identity matters, because pipeline permissions and automation tokens determine what can be merged, built, or published.

Practical implication: treat pull requests and CI pipelines as control points, not just developer convenience layers.

Shared ownership across development and security

The article points to a governance problem as much as a tooling problem. When security owns the finding but development owns the code, organisations often create a handoff loop that stretches review cycles and blurs accountability. Shared ownership models reduce that gap by making remediation part of the same operating model as delivery. For identity-heavy workflows, that also means governing who can approve, trigger, or deploy changes with the same discipline used for other high-risk access paths.

Practical implication: define remediation ownership and approval boundaries before incidents force teams to improvise.

Threat narrative

Attacker objective: The objective is to exploit delayed detection and slow remediation so vulnerable software remains deployable for longer.

1. Entry occurs when insecure code, dependencies, or AI-assisted changes are allowed to progress without security checks in the pull request or CI path.
2. Escalation follows when the issue reaches release or production, where the original context is diluted and the fix requires broader coordination.
3. Impact is delayed remediation, higher vulnerability volume, and lost engineering capacity that turns security into an operational tax.

Breaches seen in the wild

• Secrets in VS Code extensions 2025: Wiz found 550+ secrets in VS Code extensions, including publishing tokens able to push malicious updates to about 150,000 installs.
• Shai Hulud npm malware campaign: Shai Hulud campaign: npm malware exposed secrets on GitHub.

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

Reactive AppSec is a governance failure before it is a tooling failure. When organisations rely on release-time review, they are asking engineers to repair context after it has already decayed. That model increases review latency, weakens accountability, and guarantees that security will compete with delivery instead of supporting it. Practitioner takeaway: move security decisions to the point where code, ownership, and intent still align.

The real control question is not how many tools exist, but where decisions are made. Pull requests and CI pipelines are the correct governance layer because they sit inside the change process rather than outside it. This is especially relevant where code, dependencies, and automation tokens are part of the delivery chain. Practitioner takeaway: treat workflow placement as the primary design choice for AppSec.

Workflow-native security is the named concept this research points toward. Security only scales when controls are embedded where developers already work, so the path to fewer vulnerabilities and less friction is to reduce handoffs, not add gates. That does not eliminate governance; it relocates it to earlier decision points. Practitioner takeaway: design AppSec to travel with the code, not trail behind it.

Software supply chain risk and AI-assisted development make late-stage AppSec more expensive. As more changes come from generated code, transitive dependencies, and automated pipelines, the number of places where problems can enter increases, while the time available to catch them shrinks. Practitioner takeaway: align code review, dependency checks, and pipeline permissions before those changes become release blockers.

Developer capacity is now a security metric. If teams are spending hours each week on incident response, the programme is consuming the very engineering time it needs to stay resilient. High-performing organisations should measure friction, review latency, and remediation ownership alongside vulnerability counts. Practitioner takeaway: optimise for fast, accountable fixes, not just more findings.

From our research library:

• Breaches involving third parties rose to 48% of all breaches, a 60% increase on the previous year, according to Verizon's 2026 Data Breach Investigations Report.
• 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to the Ultimate Guide to NHIs.
• Read next: CI/CD Pipeline Identity Security Guide

What this signals

Workflow-native AppSec: security decisions belong inside pull requests, CI pipelines, and review paths where developers can still change the code cheaply. Once a finding waits for release or audit, the programme is paying for context loss instead of risk reduction.

The more software delivery depends on dependency chains and automation, the less effective late-stage review becomes. Teams should watch review latency, not just vulnerability counts, because slow decision cycles are often the real constraint on remediation velocity.

For practitioners

• Embed security checks in pull requests Shift routine validation into pull requests so findings appear while the author still has direct context, reducing handoff delay and rework.
• Enforce CI pipeline policy gates Use CI as an enforcement point for dependency, secret, and configuration checks so insecure changes cannot pass into build artefacts unnoticed.
• Track review latency as a control metric Measure how long security findings sit before a developer can act, then compare that delay across repositories, teams, and change types.
• Consolidate overlapping AppSec tooling Reduce duplicate scanners and fragmented workflows that force developers to reconcile multiple tickets for the same code path.
• Align AI-assisted development with policy checks Apply the same review and pipeline controls to AI-generated changes as to human-written code, especially where automation can bypass informal review habits.

Key takeaways

• Reactive AppSec turns security findings into interruptions that consume developer time instead of reducing it early in the workflow.
• The reported 40% reduction in monthly vulnerabilities for teams checking every pull request shows that control timing is a material security variable.
• Embedding checks in pull requests and CI pipelines reduces rework because fixes happen while ownership and context are still clear.

Key terms

• Reactive security: A security operating model that waits for an event to be detected before humans respond. It is often effective for known incidents, but it struggles when attacks scale quickly or when the environment changes faster than manual review can keep up.
• Pull Request Security Scanning: Pull request security scanning is the practice of evaluating code changes before they are merged into a repository. It gives developers immediate feedback on vulnerabilities, secret exposure, and dependency risk in the place where work is already happening. The goal is to catch issues early enough to fix them without disrupting delivery.
• CI Pipeline Policy Enforcement: CI pipeline policy enforcement is the automatic application of security or compliance rules during build and integration stages. If a change violates a defined threshold, the pipeline can warn, notify, or fail the build, helping teams prevent insecure code from progressing further into delivery.
• Reporting Latency: Reporting latency is the time between discovering a security issue and being able to notify the right authority with confidence. In regulated environments, long latency often reflects governance gaps in ownership, inventory accuracy, and escalation, not just slow analysis.

Deepen your knowledge

NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course. It is designed for practitioners who need to connect access, lifecycle, and governance decisions across modern delivery environments.