Bridging Dev and Security Teams

The biggest security risk in most organisations is not a technical vulnerability — it is the gap between developers and security teams. This lesson covers how to bridge that gap so security becomes a shared responsibility rather than a bottleneck.

The problem

In many organisations, the relationship between development and security teams follows a predictable pattern:

1. Developers build a feature.
2. Security reviews it late in the process (or after deployment).
3. Security finds issues and files tickets.
4. Developers view the tickets as blockers, not improvements.
5. Both sides become frustrated.

This pattern creates an adversarial dynamic. Developers see security as a team that says "no." Security sees developers as a team that does not care. Neither is true — the process is broken, not the people.

Shift left, but do it properly

"Shift left" means moving security earlier in the development lifecycle. But many organisations interpret this as "add more security gates earlier" — which just moves the bottleneck.

Effective shift-left means:

• Enable, do not gate. Give developers tools and knowledge so they can solve security problems themselves, rather than routing everything through a security review.
• Automate the easy stuff. SAST, dependency scanning, and secret detection in CI/CD should catch the low-hanging fruit automatically. If developers get immediate feedback in their pull request, they fix things before security ever needs to look.
• Reserve human review for design-level decisions. Security engineers should spend their time on threat modelling, architecture review, and complex logic — not finding missing CSRF tokens in code review.

What developers need from security teams

• Clear, actionable guidance. "Fix the XSS" is not helpful. "Encode the username variable using htmlspecialchars() before rendering it in profile.php line 47" is.
• Context-appropriate risk ratings. Not everything is critical. If the security team marks every finding as high severity, developers learn to ignore severity ratings entirely.
• Availability. Developers should be able to ask a quick question and get a quick answer. If the only way to get security input is a formal review request with a 2-week SLA, developers will just ship without it.
• Empathy for deadlines. Developers work under real delivery pressure. Security guidance that ignores business timelines will be ignored.

What security teams need from developers

• Early visibility into design decisions. The time to discuss authentication architecture is during design, not after the feature ships. Invite security to design reviews for sensitive features.
• Honest responses to findings. "We will fix it later" often means "we will never fix it." If a risk is being accepted, say so explicitly and document it.
• Willingness to learn. Security is a skill that improves with practice. Developers who invest in understanding common vulnerabilities produce dramatically fewer bugs.
• Consistent application of controls. A parameterised query in one endpoint and string concatenation in the next means the training did not stick.

Security champions

A security champion is a developer on a product team who takes a special interest in security. They are not a replacement for a security team — they are a bridge.

The security champion model works because:

• Proximity. A champion on the team understands the codebase, the architecture, and the business context far better than an external reviewer.
• Scale. A security team of 5 cannot deeply review the output of 200 developers. Twenty security champions can cover far more ground.
• Culture. When security advocacy comes from a peer rather than an external team, it is received differently.

A typical security champion programme:

• Identify 1–2 volunteers per product team
• Give them additional training (beyond what all developers receive)
• Include them in security team communications and planning
• Recognise their contribution (it is extra work)
• Have them lead threat modelling sessions and review security-relevant PRs within their teams

Making security reviews collaborative

Bad security review: Security sends a 40-page PDF of findings ranked by CVSS score, two weeks after the feature shipped.

Good security review:

• Scope it. Review the specific change, not the entire application. Focus on new trust boundaries, new data flows, and new user roles.
• Do it together. Pair with the developer. Walk through the code together. Explain why something is a risk, not just that it is.
• Provide fix suggestions. Better still, provide a code snippet or a link to the relevant pattern from your internal guidelines.
• Agree on timelines. Some findings need to be fixed before merge. Others can be tracked and addressed in the next sprint. Be explicit about which is which.
• Follow up. Check that the fixes actually landed and are correct.

Shared language

Security jargon alienates developers. Developer jargon alienates security teams. Agree on a shared vocabulary:

• Instead of "the application is vulnerable to CWE-89," say "the search endpoint builds SQL queries with string concatenation — an attacker can modify the query."
• Instead of "this violates PCI requirement 3.4," say "credit card numbers are stored in plaintext in the database — they need to be encrypted."
• Instead of "we need to refactor the entire auth module," say "the session token is stored in localStorage, which is accessible to XSS — we should move it to an HttpOnly cookie."

Technical accuracy matters, but clarity matters more.

Measuring the relationship, not just the bugs

Metrics that help:

• Time from finding to fix — is it getting shorter? If so, the relationship is working.
• Findings per sprint over time — are the same classes of bugs recurring, or is the team learning?
• Threat models completed — is security being considered before code is written?
• Developer training completion — not just attendance, but follow-through (do developers reference training materials when making decisions?)

Metrics that hurt:

• Number of vulnerabilities found as a performance metric for the security team. This incentivises finding more bugs, not preventing them.
• Zero vulnerabilities as a performance metric for the development team. This incentivises hiding bugs, not fixing them.

Summary

The gap between development and security teams is bridged by clear communication, early engagement, shared language, and mutual empathy. Security champions extend the security team's reach. Collaborative reviews build trust. The goal is not fewer findings — it is fewer surprises, faster fixes, and a culture where both teams own the outcome.