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.
Editorial analysis by NHI Mgmt Group, based on content published by Kusari: “The Hidden Cost of Reactive AppSec”.
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.
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.
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.
Practitioner guidance
- 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.
Bottom line: Reactive AppSec turns security findings into interruptions that consume developer time instead of reducing it early in the workflow.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
18/08/2026 3:31 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Reactive AppSec is draining developer capacity and delaying fixes