How should security leaders reduce friction between security and development teams in application security programmes?

Security leaders should treat friction as a workflow design problem, not a people problem. The most effective approach is to embed security earlier, prioritise issues that matter most to delivery risk, and automate repeatable checks so developers are not forced into manual rework. The goal is to preserve release speed while making secure choices the path of least resistance.

Why Friction Fades When Security Fits the Delivery Workflow

Security leaders reduce friction by designing controls around how teams already build, review, and ship software. That means security checks should appear at natural handoff points, use the same tooling developers already trust, and produce clear, actionable findings rather than broad risk statements that force extra interpretation.

When security is bolted on after coding, developers experience it as interruption. When it is embedded into planning, pull requests, CI/CD, and release gates, security becomes part of the delivery system itself. That shift matters because the team is no longer asking developers to translate security intent into engineering action on their own.

The most effective programmes also reduce uncertainty. Clear severity rules, predictable exceptions, and fast feedback loops prevent teams from re-litigating the same issues on every release. For application security leaders, the real goal is not “more security reviews”, it is fewer ambiguous moments where developers must guess what secure means.

Make the default path secure, so a developer has to opt out rather than opt in.
Push checks earlier, where fixes are cheaper and easier to reason about.
Use common templates and agreed definitions so findings are interpreted consistently.

How to Prioritise Work So Developers Do Not Feel Buried

Friction often comes from volume, not from security itself. If every issue is treated as equally urgent, development teams quickly learn to ignore the queue, challenge the process, or route around it. Prioritisation should reflect release risk, exploitability, and whether the issue blocks safe delivery.

This is where leaders need discipline. If the team cannot distinguish between critical exposure and low-value noise, the programme creates churn instead of protection. Triage rules should make it obvious which issues demand immediate engineering attention, which can be scheduled, and which can be accepted with documented rationale.

Automation helps here, but only when it reduces manual review rather than adding another layer of gates. A scanner that produces hundreds of low-confidence findings will increase resistance unless it is tuned, deduplicated, and paired with clear ownership. A smaller, better-curated backlog usually drives more security adoption than a larger one with more coverage.

Rank findings by delivery impact, exploitability, and likely blast radius.
Eliminate duplicate or low-confidence alerts before they reach developers.
Define clear escalation rules for issues that truly block release.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

CIS Controls v8, NIST CSF 2.0 and NIST SP 800-63 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
CIS Controls v8	CIS Control 16 — Application Software Security	Application security programmes need secure-by-design checks embedded into delivery workflows.
	CIS Control 8 — Audit Log Management	Fast feedback and developer accountability improve when security actions are observable and traceable.
Recommendation — Embed security testing and review into the software development lifecycle. Centralise and retain logs for security-relevant build and release activity.
NIST CSF 2.0	GV.SC — Cyber Supply Chain Risk Management	AppSec friction drops when security ownership and third-party dependencies are governed early.
	PR.IP — Information Protection Processes and Procedures	Repeatable, documented security checks reduce ambiguity and manual rework in development.
Recommendation — Define supply-chain security expectations across development and delivery partners. Standardise secure development procedures and integrate them into delivery processes.
NIST SP 800-63	IAL — Identity Assurance Level	Risk-based verification and step-up decisions mirror the question's need to apply heavier review only where needed.
Recommendation — Apply assurance levels to match control strength with risk.

Practitioner Guidance

What to prioritise: Fix the workflow before you ask for better behaviour. If security reviews are slow, inconsistent, or hard to interpret, developers will treat them as friction even when the underlying control is sound.

Decision rule: If a check can be automated reliably, automate it; if a decision requires context, keep it human but make the decision path explicit and lightweight. That distinction prevents teams from turning every control into a manual approval step.

What to measure: Track review lead time, rework rate, and the proportion of findings that are actionable on first pass. Those signals show whether security is helping teams ship safely or simply adding queue time.

Practitioner takeaway: The fastest way to reduce friction is to make the secure path the easiest engineering path, then reserve human judgement for the few decisions that truly need it.

What Good Collaboration Looks Like in Practice

Healthy security-development collaboration is visible in the structure of the programme. Security reviews are integrated into product planning, developers receive findings in the tools they already use, and the team shares a common definition of what matters enough to interrupt delivery. That makes security a delivery enabler rather than a separate approval function.

This is also where leadership matters most. Security leaders should sponsor a working agreement between the teams: what gets checked automatically, what gets reviewed manually, how exceptions are handled, and who owns remediation. Without that agreement, each incident or release deadline becomes a new negotiation, which is where resentment tends to grow.

For leaders trying to improve adoption, the best sign is not that developers never complain. It is that they stop needing translation. When security guidance is specific, repeatable, and embedded in delivery tooling, teams spend less time debating process and more time fixing the actual risk.

Agree which controls are mandatory, which are advisory, and which are release-blocking.
Route findings to the right owner with enough context to act immediately.
Use exceptions sparingly and require a documented expiry or review date.

Practitioner takeaway: Collaboration improves when security behaves like a product service to engineering, with clear service levels, stable decision rules, and feedback that helps teams ship safely the first time.