Topic starter
02/08/2026 11:33 am
TL;DR: Late security feedback turns AppSec into a delivery risk when findings arrive without release context, according to OXSecurity. Without shared code, pipeline and runtime context, teams spend more time on rework and less on fixing issues before release.
Editorial analysis by NHI Mgmt Group, based on content published by OXSecurity: “A Costly Divide: 5 Ways to Stop AppSec and Dev from Working Against Each Other”.
By the numbers:
- AppSec friction with development was the top pain point for 39% of respondents in OXSecurity’s FS-ISAC 2024 Americas Fall Summit poll.
- Lack of integration with DevOps tools received 18% of votes in OXSecurity’s poll.
- Alert fatigue and prioritization accounted for 19% of votes in OXSecurity’s poll.
Key questions
Q: Why do disconnected development tools increase risk in modern software delivery?
A: Disconnected tools create blind spots.
Q: What do security teams get wrong about appsec alert volume?
A: They often treat more findings as more security, when the real problem is whether the findings are true, reachable, and worth fixing.
Q: What breaks when AppSec findings are not routed into developer workflows?
A: Findings lose context, ownership becomes unclear, and the work shifts into tickets and handoffs that developers tend to deprioritise.
Practitioner guidance
- Embed AppSec checks in delivery pipelines Run security scanning inside CI/CD and pull-request workflows so developers see issues where code is still being changed.
- Add source and runtime context to findings Correlate each finding to the affected function, dependency, build step, and deployment context before assigning remediation work.
- Prioritise exploitability over raw severity Rank issues using reachability, exploitability, and business impact so teams focus on the findings most likely to matter in production.
Bottom line: AppSec and development misalignment becomes a delivery risk when security findings arrive too late to shape release decisions.
Glossary terms: Application Security Testing Service, Shift-left security, Remediation velocity, Security Champion
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 2 days ago by NHI Mgmt Group
02/08/2026 12:47 pm
AppSec misalignment is now a governance failure, not a tooling inconvenience. When development and security measure success with different clocks, late findings turn into release blockers and organisational waste. The real issue is that the control plane is split across delivery and assurance, so no one owns the full path from code change to production risk. Practitioners should treat this as a governance design problem, not a communication problem.
A question worth separating out:
Q: How should organisations align developers and security teams in AppSec?
A: They should treat AppSec as a shared operating model, not a handoff after code is finished. That means training developers with evidence from real findings, using tools that explain issues clearly, and setting remediation expectations that fit delivery realities. Trust improves when security helps teams ship safely, not just block release.
👉 Read our full editorial: AppSec and development misalignment is now a delivery risk