Balance security and development by agreeing in advance what blocks a release, putting checks where developers already work, and giving fixes a share of each sprint. Conflict usually comes from vague risk and late gates, not from bad faith. Written severity rules settle most arguments before they start.
Why do the two teams clash?
Developers are measured on what ships. Security is measured on what does not go wrong. A security review that arrives the day before release looks like an obstacle, and a feature deadline looks like carelessness to the reviewer. Both are responding sensibly to their incentives.
NIST's Secure Software Development Framework, SP 800-218, argues the fix is structural. It describes a core set of practices that can be added to any development life cycle, and it says following them should reduce vulnerabilities in released software and address root causes so they do not recur. The word to notice is "integrated": security as steps in the normal flow, not a separate phase at the end.
What should block a release?
Write it down. A short policy might say a release is blocked by a confirmed critical finding in code that is reachable from the internet, by a secret committed to the repository, or by a dependency with a known exploited vulnerability that has a fix. Everything else becomes a ticket with an owner and a date.
The CISA Known Exploited Vulnerabilities catalog is useful here because it is a public list of vulnerabilities with evidence of exploitation in the wild. "Appears in the catalog and we use it" is a far easier conversation than "the scanner says high."
Where should the checks live?
Where the developer already is. A check in the pull request, with a clear message and a suggested fix, gets handled in minutes. A PDF from a quarterly audit gets argued about for weeks. Fast checks, such as secret detection and dependency lookups, belong in the editor or on commit. Slower ones, such as full static analysis, belong in the pipeline with results posted back to the pull request.
False positives decide whether developers trust the process. Keep a path to mark a finding as not applicable with a reason, and review those marks so they cannot become a silent bypass.
How do you pay for fixes?
Treat fix work as planned work. One simple method is a fixed share of each sprint for security and reliability tasks, agreed with product management, not requested fresh each time. When a critical item arrives, it displaces something visible and everyone sees the tradeoff.
A constructed example: a team of eight reserves roughly one story in five for security fixes. A new advisory lands for a library they use. Because the time is already budgeted, the upgrade ships that week and nobody had to escalate. The following sprint, the team spends its share on removing an unused dependency to shrink future exposure.
What does the security team owe in return?
Speed and clarity. Triage new findings within an agreed time, say what the exploit path is, and avoid dumping a raw backlog on a team. Share the reason for each rule. Developers follow rules they understand.
Safeguard can help with the evidence side: reachability analysis shows whether a vulnerable function is actually called, so the blocking list stays short, and policies and gates let a team encode the release rules above and enforce them in pull requests.
How to check or apply this
- Write a half-page release policy listing exactly what blocks a ship.
- Move secret and dependency checks to commit or pull request time.
- Add an allowed-exception process with an owner and an expiry date.
- Reserve a fixed share of each sprint for security work.
- Track time from finding to fix, and review it monthly with both teams present.
- Retire any rule that nobody can explain.
Quick check
Who decides when security and a deadline conflict?
The business owner of the product, with the risk written down. The release policy should say in advance which findings are never waived.
Sources
Last reviewed: 18 October 2026.
