The most expensive security problem in most organisations isn't a vulnerability. It's the relationship. Developers build, security reviews late and files tickets, developers see blockers landing on a finished feature, and the whole thing turns adversarial. That's a broken process, not bad people, and a broken process is something you can fix.
Shift left, but do it properly
"Shift left" gets misread as "add more gates, earlier." That just moves the bottleneck closer to the start of the work. The version that actually helps is about moving capability left, not control.
- Enable, don't gate. Give developers the tools and knowledge to solve security problems themselves.
- Automate the boring half. SAST and dependency scanning belong in CI, running without anyone asking.
- Save humans for the hard half. Threat modelling and architecture review are worth a person's time. Hunting for a missing CSRF token is not.
What developers need from security
- Guidance they can act on. Not "fix the XSS." Which variable, in which function, rendered where.
- Severity that means something. If every finding is "high," developers learn to ignore the label entirely.
- Someone reachable. A quick question should get a quick answer, not a two-week ticket.
What security needs from developers
- Early visibility. An invitation to the design review for anything sensitive, while the design can still change.
- Honest answers. "We'll fix it later" usually means never. If you're accepting a risk, accept it out loud and write it down.
Security champions
A security champion is a developer on the product team who has taken an interest in this stuff. They're a bridge, not a replacement for security expertise, and they work because of where they sit.
- They already have the codebase and the context in their head.
- They scale. Twenty champions across the org beat a five-person security team trying to review two hundred developers.
- Advice from a teammate lands differently than the same advice from an outside reviewer.
Reviews that build trust
The bad version is a forty-page PDF that arrives two weeks after the feature shipped. The good version is a person: pair with the developer, walk the code together, hand over fix snippets rather than findings, agree a realistic timeline, and actually follow up.
Get the engagement early, share a vocabulary, and assume good faith on both sides. Do that and the surprises get fewer, the fixes get faster, and security stops being something done to the team and becomes something the team owns.