Notifications
Clear all
Topic starter
18/08/2026 2:49 pm
TL;DR: Nearly half of respondents spend five or more hours each week on security incidents, while teams that assess security on every pull request report 40% fewer monthly vulnerabilities, according to Kusari’s Application Security in Practice report. The finding is that late-stage AppSec has become a productivity tax, and security leaders now need workflow-native controls rather than release-time checks.
NHIMG editorial — based on content published by Kusari: Application Security in Practice research on developer friction and reactive AppSec
Questions worth separating out
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.
Q: Why do release-time AppSec checks create more remediation work?
A: Because they arrive after code, dependencies, and ownership have changed.
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.
Practitioner guidance
- 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.
- Track remediation latency as a governance metric Measure the time from finding to fix, not just the number of findings.
- 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.
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
👉 Read Kusari's application security research on developer friction and shift-left controls →
Reactive AppSec and developer friction: what teams need to change?
Explore further
18/08/2026 3:31 pm
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.
A question worth separating out:
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.
👉 Read our full editorial: Reactive AppSec is draining developer capacity and delaying fixes
