You break down silos between developers and security by giving both teams one goal, one queue and one set of numbers. When a vulnerability is a ticket in the engineering backlog, with an owner and a deadline both sides agreed, the arguments about whose problem it is mostly stop.
Why do silos form?
Silos are not a personality problem. They come from structure.
- Security is measured on risk reduced and incidents avoided. Engineering is measured on features shipped and uptime. Each side optimizes what it is measured on.
- Findings arrive in a security tool that developers never open.
- Reviews happen at the end, so security is the last person to say no.
- Language differs. A security report says "CWE-79, severity high". A developer wants to know which file and what to change.
NIST's Secure Software Development Framework (SP 800-218) treats this as an organizational task. Its first group of practices is about preparing the organization: defining roles and responsibilities, and providing training and support for the people building the software. The framework assumes the work is shared.
What does a shared goal look like?
Pick two or three outcomes that both teams are accountable for. Good ones are measurable and neutral:
- Median time from a vulnerability being found to being fixed, by severity.
- Share of repositories with the standard pipeline checks turned on.
- Number of high severity issues older than an agreed limit.
Avoid counting raw findings. A team that is rewarded for fewer findings may simply turn off scanners.
How do you share the queue?
Put security work where engineers already plan work. If your teams use one tracker, security findings become tickets there, tagged and ranked, and get discussed in the same refinement meeting as features. Security can still keep a private view for reporting, but the unit of work is shared.
Give each ticket enough detail to act on: the file, the line, why it matters in this application, and a suggested fix. Fewer, better tickets beat a flood.
A constructed example
A company has twelve product teams and a four person security group. Security sends a monthly spreadsheet of 900 findings. Developers file it under "later". After a quarter, the leaders change three things. Findings go straight into each team's backlog, filtered to those reachable in production code. Each team picks a champion, a developer who spends a few hours a week on security and joins a fortnightly call with the security group. The monthly spreadsheet is replaced by one chart showing time to fix by team.
Within two quarters the mood changes. Developers ask security for help earlier, because the champion has made it normal to ask.
What role do champions play?
A champion is a developer who carries security knowledge into the team. They are not the only person responsible. They help triage findings, review risky changes, and tell the security group when a rule is noisy. OWASP SAMM describes governance, design, implementation, verification and operations as business functions, and gives a way to assess where each team stands. It is a useful way to talk about progress without blame.
What habits help every week?
- Blameless reviews. After an incident, ask what made the mistake easy, not who made it.
- Early involvement. Invite security to design talks for sensitive features, with a short agenda.
- Feedback on tools. Let developers mark a finding as wrong, and let security fix the rule.
- Visible wins. Share a monthly note on vulnerabilities fixed and time saved.
- Rotation. Let a security engineer spend a week with a product team, and a developer a week with security.
How to check or apply this
- Ask five developers where they last saw a security finding, and whether they could act on it. Their answers show the gap.
- Choose one shared metric and chart it publicly.
- Move findings into the engineering tracker for one pilot team.
- Name a champion in that team and give them time on the calendar.
- Run a short retrospective after one quarter and decide what to extend.
Quick check
Who should own fixing a vulnerability?
The team that owns the code owns the fix. Security helps with priority, advice and tooling.
What is the quickest sign of a silo?
Findings that sit unread in a tool nobody on the engineering team opens.
Sources
- NIST SP 800-218, Secure Software Development Framework (SSDF) Version 1.1
- OWASP SAMM
- CISA, Secure-by-Design
Last reviewed: 18 October 2026.
