Reactive AppSec is draining developer capacity and delaying fixes

At a glance

What this is: Kusari’s research finds that reactive AppSec is consuming developer time and surfacing risk too late to fix efficiently.

Why it matters: For IAM and security teams, the lesson is that controls must fit into delivery workflows or they will create delay, fragmented ownership, and weaker governance across software and its secrets.

By the numbers:

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

👉 Read Kusari's application security research on developer friction and shift-left controls

Context

Reactive application security fails when findings arrive after code, dependencies, and ownership have already shifted. In that model, the team is not governing risk in real time; it is cleaning up after release, audit, or production exposure, when remediation is slower and more expensive.

The primary identity angle is not human IAM, but the security of the software delivery chain that increasingly carries secrets, access paths, and machine credentials. When application security stays detached from developer workflows, it also weakens governance over secrets, service accounts, and the build and deployment paths that depend on them.

Key questions

Q: How should security teams reduce AppSec noise without weakening control?

A: Start by gating only newly introduced risk and moving low-friction checks earlier in the developer workflow. That lets teams keep inherited backlog issues visible without turning every pull request into a re-review of old debt. The result is better signal, less merge friction, and higher developer trust in the control plane.

Q: Why do release-time AppSec checks create more remediation work?

A: Because they arrive after code, dependencies, and ownership have changed. At that point, teams must reconstruct context before they can fix anything, which increases cost and delay. Continuous checks reduce that loss of context and make remediation part of normal delivery rather than a crisis response.

Q: What do AppSec teams get wrong about shift-left testing at scale?

A: They often treat shift-left as a tool deployment rather than a workflow change. That leads to slow scans, manual handoffs, and findings that developers cannot easily action. The better approach is to design for developer adoption first, then prove security value through metrics that leadership and engineering both understand.

Q: How can organisations measure whether AppSec controls are working?

A: They should look for fewer repeat vulnerabilities, lower false-positive burden, faster developer adoption, and measurable reduction in high-risk bug classes. A healthy AppSec programme changes the shape of risk, not just the number of alerts. If findings remain high but exposure does not fall, the control model is not scaling.

Technical breakdown

Why release-time security checks create remediation debt

Release-time checks compress detection, triage, and ownership into the worst possible moment. By then, the codebase has moved on, dependency graphs have changed, and the developer who introduced the issue may no longer be the right owner. That creates remediation debt, where every delayed finding costs more effort because context must be reconstructed before a fix can begin. In practice, the control failure is not absence of scanning, but absence of continuous decision points inside the development flow.

Practical implication: move findings earlier in the pipeline so ownership and context are still intact when action is cheapest.

How pull-request and CI controls reduce vulnerability growth

Pull-request and CI integration turns AppSec into a gating function rather than a post-release review function. The value comes from repeated, low-friction checks on every change, which reduces the chance that vulnerable code or risky dependencies reach shared branches. This also matters for secrets and machine credentials, because build-time and commit-time checks are where exposed tokens and hardcoded credentials can be intercepted before they propagate into production. The mechanism is workflow proximity, not more reporting.

Practical implication: enforce security checks where developers already work, especially in pull requests and CI pipelines.

Why tooling sprawl undermines shared ownership

Fragmented AppSec toolchains often create more noise than governance. When dependency scanning, secret detection, policy checks, and review systems live in separate consoles, teams lose a coherent view of risk and spend more time reconciling findings than fixing them. Shared ownership also breaks down because developers and security teams see different slices of the same problem. Consolidation does not mean one tool for everything, but one operating model for how findings are triaged, routed, and closed.

Practical implication: standardise triage and ownership across tools so security findings become one workflow, not several disconnected queues.

NHI Mgmt Group analysis

Reactive AppSec is a governance failure before it is a tooling problem. Kusari’s findings show that late detection creates an organisational tax by shifting work from prevention into interruption. The issue is not simply that more vulnerabilities exist, but that they arrive after accountability, code context, and release decisions have already drifted. For security leaders, the field-level implication is that governance must move into delivery flow, not sit beside it.

Software delivery now behaves like an identity-bearing control plane. When pull requests, CI pipelines, and deployment systems move code, secrets, and access paths, they also become governance surfaces. That means application security is no longer isolated from identity security, because machine credentials and service access often travel through the same workflows as the code itself. Practitioners should treat the delivery pipeline as part of the trusted control environment.

Developer friction is a measurable security risk, not a soft complaint. If teams spend five hours or more each week reacting to incidents, that is capacity removed from engineering, hardening, and review. High-performing teams reduce this friction by putting controls where work already happens, which aligns with NIST CSF protect and detect functions and makes security measurable in workflow terms. The practitioner takeaway is that friction must be managed as risk.

Shared ownership is the missing operating model for modern AppSec. The article shows that effective teams do not merely add more checks, they align development and security around common review latency, dependency visibility, and remediation responsibility. That is a structural change in governance, not a point solution. In practice, teams should redesign handoffs so findings have a single owner and a single closure path.

Secrets exposure sits inside the AppSec problem set even when the article does not name it explicitly. Application security workflows increasingly protect the code paths where API keys, tokens, and other secrets appear, and that makes secret governance part of everyday AppSec rather than a separate hygiene exercise. The broader control lesson aligns with the OWASP Non-Human Identity Top 10 and should push teams to connect code review, CI policy, and credential lifecycle management.

What this signals

AppSec programmes that stay outside developer workflows will continue to miss the point. The practical signal is whether review, triage, and remediation can happen before release, not after production exposure.

Remediation latency debt: when findings arrive after context has moved on, each fix consumes more engineering time than the risk itself justified. That is why teams should monitor review latency alongside vulnerability counts and treat the two as linked indicators.

The broader direction is toward governance models that connect code review, dependency control, and secrets lifecycle management. Teams that can tie those functions together will reduce friction without lowering assurance.

For practitioners

• Embed security checks into every pull request Make pull-request review the default security decision point so issues are found while code context and ownership are still fresh. Use automated checks to reduce manual backlogs and to keep review latency visible to both engineering and security leaders.
• Track remediation latency as a governance metric Measure the time from finding to fix, not just the number of findings. If a control generates work that cannot be closed quickly, it is not improving governance and may be shifting risk into later stages of delivery.
• Consolidate security findings into a single triage flow Unify secret scanning, dependency alerts, and policy violations into one ownership model so teams do not lose time reconciling multiple queues. A single triage path helps developers know what to fix, who owns it, and when it can ship.
• Align software delivery controls with secrets governance Treat hardcoded credentials, exposed tokens, and CI pipeline secrets as part of the AppSec backlog, not a separate incident class. Connect code review, CI policy, and revocation workflows so secrets found in development can be acted on before release.

Key takeaways

• Reactive AppSec turns security into interruption, which slows delivery and increases the cost of every fix.
• Security teams should measure remediation latency and workflow friction, not just vulnerability volume.
• Controls that live inside pull requests and CI pipelines are far more likely to reduce risk before release.

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.
• Shift-left security: Shift-left security means moving security checks and remediation earlier in the software delivery lifecycle, especially into development and pull request workflows. The goal is to surface issues when they are cheapest to fix and closest to the code change that introduced them.
• Remediation Latency: The time between identifying a security issue and fully removing or reducing the risk. For NHIs and SaaS access, this metric matters because stale credentials, over-shared files, and dormant integrations stay usable until the control finally acts.
• Secret Lifecycle Management: Secret lifecycle management is the practice of creating, rotating, expiring, revoking, and retiring credentials according to policy. It turns secret handling from a one-time setup task into an ongoing governance process, which is essential when credentials are distributed across cloud, CI/CD, and automation environments.

What's in the full report

Kusari’s full research report covers the operational detail this post intentionally leaves for the source:

• Survey breakdowns by developer and security role, useful for comparing how each group experiences AppSec friction
• The report’s workflow findings on pull requests, CI pipelines, and release-stage review latency
• Practical maturity signals for teams trying to reduce remediation drag without adding more tool sprawl
• The underlying survey context for organizations benchmarking their AppSec posture against peers

👉 Kusari’s full report includes the survey detail, workflow findings, and team practices behind the headline results.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, secrets management, and workload identity. It helps practitioners connect identity controls to the workflows where credentials and access paths are actually created and used.