Traditional AppSec often adds friction because it introduces extra review steps, blocked merges, noisy scan results, and remediation tasks with limited context. Those interruptions break developer flow, slow delivery timelines, and raise frustration. When security appears as a gatekeeper instead of a workflow aid, teams are more likely to treat findings as obstacles rather than actionable risk signals.
Why AppSec Friction Becomes a Delivery Problem
Traditional AppSec creates friction when it is inserted as a separate checkpoint rather than embedded into the way teams design, build, test, and ship software. The issue is not security review itself, but the way review, prioritisation, and remediation are often detached from engineering context. When findings arrive too late, too broadly, or without clear ownership, they compete with feature work instead of supporting it.
That pattern matters because engineering teams quickly optimise for throughput, while security teams are accountable for risk reduction. If the process adds delay without improving decision quality, developers experience it as rework, not protection. The result is predictable: workarounds, alert fatigue, and shallow compliance behaviour that improves the appearance of control more than the actual risk posture. In practice, many security teams encounter resistance only after repeated blockers have already trained engineers to see security as an external approval layer rather than a shared delivery function.
For a useful contrast, OWASP’s Non-Human Identity Top 10 shows how risk becomes easier to act on when guidance is anchored to a specific operational domain instead of broad, catch-all findings.
How Traditional AppSec Interrupts Engineering Workflows
AppSec friction usually comes from process design, not from the existence of security requirements. The most common failure mode is a control path that is too generic for the software team it is meant to help. A scanner may surface hundreds of findings, but if the output is not triaged by exploitability, service criticality, or release timing, the team receives volume rather than direction. Likewise, a late-stage manual review can force decisions when code is already merged, tested, and scheduled for release, which makes security feel like an interruption to a finished plan.
Another source of friction is poor translation between security language and engineering language. Developers need to know what breaks, what is exploitable, what is urgent, and what can wait. Security teams often have the right concern but the wrong packaging: too much severity, too little context, or no practical path to closure. That creates a trust gap, especially when the same workflow blocks low-risk issues and high-risk issues in the same way.
- Findings become more useful when they are tied to the code path, deployment stage, and owner that can actually fix them.
- Blocking controls work better when they are reserved for high-confidence, high-impact conditions rather than every policy exception.
- Fast feedback matters because remediation effort rises sharply once the team has already moved on to other work.
Used well, AppSec should reduce uncertainty and rework, not add another queue between engineering intent and production delivery. It breaks down when security tooling produces static verdicts that are disconnected from how the product is built, released, and maintained.
Where the Friction Is Highest and What Teams Often Miss
Tighter security review often improves assurance, but it also increases coordination overhead, so teams have to balance stronger gating against delivery speed and developer attention. That tradeoff becomes most visible in edge cases: shared libraries, platform teams, high-velocity release trains, and services that inherit many dependencies. In those environments, one-size-fits-all AppSec processes tend to over-penalise routine changes while still missing the issues that matter most.
There is also a broader governance issue: when findings are treated as universal blockers, engineering teams stop distinguishing between advisory, important, and release-critical issues. That weakens both sides of the relationship. Security loses signal quality because everything looks equally urgent, and engineering loses trust because the process does not reflect operational reality. The industry does not fully agree on how prescriptive AppSec should be here, but there is broad agreement that feedback must be risk-based, timely, and actionable.
The hidden cost is organisational, not just procedural. Once teams internalise that security reviews create predictable delay, they start designing around the review rather than with it, which encourages late escalation and narrow compliance thinking. That is why friction is often a sign that the control model is misaligned with delivery behaviour, not simply that teams are moving too fast.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK address the attack surface, CIS Controls v8 and NIST CSF 2.0 set the technical controls, and ISO/IEC 42001:2023 define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | 16 — Application Software Security | Covers secure SDLC and reducing friction in application security workflows. |
| Recommendation — Integrate security checks into the SDLC so findings arrive earlier and are easier to fix. | ||
| NIST CSF 2.0 | PR.IP-1 — Establish and Maintain Baseline Configurations | Supports embedding repeatable security practices into delivery processes. |
| DE.CM-8 — Vulnerability Scans Are Performed | Addresses scan-driven feedback loops that often create noisy AppSec friction. | |
| Recommendation — Standardise security review points so teams get consistent, predictable controls. Tune scanning and triage so alerts map to actionable engineering work. | ||
| MITRE ATT&CK | T1190 — Exploit Public-Facing Application | Relevant where AppSec friction masks exploitable application weaknesses. |
| Recommendation — Prioritise fixes that reduce exposure on internet-facing services first. | ||
| ISO/IEC 42001:2023 | 6.1 — Actions to Address Risks and Opportunities | Applies where security governance must be balanced against delivery impact. |
| Recommendation — Use risk-based governance to avoid imposing uniform controls on all changes. | ||
Practitioner Guidance
What to prioritise: Focus first on reducing avoidable friction in the highest-volume paths, not on adding more review coverage. If the same control blocks low-risk changes and high-risk changes equally, the process is too blunt to earn engineering trust.
What to verify: Check whether findings are reaching the team with enough context to decide severity, owner, and fix path in one pass. Good AppSec output should help a developer choose action, not require a second interpretation cycle from security.
Common mistake: Treating every issue as a gate. That approach often creates compliance theatre, where teams close tickets to move forward but do not internalise the underlying risk signal.
What good looks like: Engineers see security input as part of normal delivery, with the strongest controls reserved for the smallest set of truly high-risk conditions. The practical test is whether teams can ship safely without learning to bypass the process.
Practitioner takeaway: The best AppSec programmes reduce uncertainty early enough that engineers can still act, because once security becomes a late-stage veto, it stops being a control and starts being a bottleneck.
Related resources from NHI Mgmt Group
- Why do traditional application security scanners create operational drag in modern engineering teams?
- Why do traditional AST-based analysis frameworks create more friction for application security teams?
- Why does traditional SAST often create risk in fast-moving application teams?
- Why does CTEM mobilisation often create friction between security and operations teams?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 9, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
