Security people sometimes get discouraged because nobody cares about security like they do. But that is not true. There are people across every organization who care about security. The challenge is finding them, building relationships with them, and turning them into advocates. Dustin Lehr, Senior Director of Platform Security at Fivetran and Co-founder of Catalyst Security, spent 13 years as a software engineer before moving into cybersecurity leadership. He shares how to build security champion programs that actually change culture, why you should start security from the right side (production) rather than the left (source code), and why security should not be a startup’s top priority on day one.
You can read the complete transcript of the episode here >
When should organizations start prioritizing security?
Dustin takes a contrarian position for a security person: security should not be a startup’s day-one priority.
- Pre-product-market fit: Focus on building the business. You have little risk because you have little to protect. Best practices are fine, but security should not be the top priority.
- Post-product-market fit: Now you have customers, data, and reputation to protect. This is when security investment should begin.
- The common mistake: Companies find product-market fit and then keep chasing the next feature, next customer, never turning around to build a resilient product. That delay creates compounding risk.
The driver for initial security investment is often customers themselves. As organizations pursue larger customers, those customers demand compliance certifications, security questionnaires, and evidence of controls. Achieving SOC 2 compliance is often the first milestone. This market pressure naturally initiates the security journey.
Why should you start security from the right, not the left?
This challenges the popular “shift left” narrative. Dustin argues that starting from production (the right side) makes more practical sense:
- Understand your current reality first: Pen testing, monitoring, and incident detection in production show you what is actually happening, not what might be happening.
- Measure before you optimize: If you implement code scanning and training without production baselines, how do you know you are making a difference?
- Justify further investment: Production findings provide concrete evidence for leadership conversations. “We found active intruders in our environment” gets attention. “We found 500 SAST findings” does not.
- Then shift left progressively: Once you understand your production reality, implement shift left controls (code scanning, training, secure SDLC) and measure whether they reduce production defect density.
Root cause analysis of production incidents further justifies process changes. When an incident occurs, tracing it back to a missing code review or inadequate testing builds the case for preventive controls at earlier stages.
What is a security champion program and how does it work?
Security champion programs find allies across the organization who advocate for security on behalf of their teams. This approach to scaling security champions has proven effective across organizations of all sizes, and it complements broader application security initiatives:
- Start by finding allies: People who already care about security exist in every organization. Find them and invest time in them.
- Diffusion of innovation: Champions create a tipping point. One person per team who advocates for security reaches more people than the security team ever could alone.
- Peer influence: People are more likely to listen to their peers than to the security team. When a trusted teammate delivers the same message as a security person, it lands differently.
The process for building a champion program:
- Define goals: What specific metrics are you trying to influence? Make them SMART (specific, measurable).
- Identify your audience: Who will you invite? Senior engineers? Cross-functional roles? Beyond engineering?
- Understand motivations: What makes these people tick? What would motivate participation?
- Define desired behaviors: What specific actions do you want champions to take? Report phishing? Raise security concerns in design reviews? Advocate for secure defaults?
- Create engagement channels: Monthly brown bags, dedicated Slack channels, direct relationships between security team members and business lines.
- Measure and demonstrate ROI: Track attendance, participation, reported issues, and cultural metrics over time.
How do you get leadership buy-in for security programs?
Dustin’s approach focuses on speaking the language of the business:
- Quantify risk in business terms: Reputation damage, customer acquisition impact, regulatory fines. Not “500 vulnerabilities.” A mature approach to threat modeling helps frame these conversations.
- Show customer demand: Implementing security controls to win a specific customer is an easy win that demonstrates direct ROI.
- Position as differentiator: In competitive markets, strong security posture can be the deciding factor for customers choosing between providers.
- Invite leadership into the conversation: Show your findings and ask “What do you think? Is this a problem?” rather than dictating solutions.
The key insight: if you show leadership everything you consider a problem and they say “that is fine,” you must adjust your approach. The conversation should be collaborative, not adversarial. Open the books, invite feedback, and let the data drive decisions together.
How do you build security-first culture?
Culture change requires relationship building, not mandates from an ivory tower. Building a security culture takes deliberate effort:
- Earn your seat at the table: Being hired as the security person does not automatically give you influence. You earn it by providing value and speaking in terms others understand.
- Overcome the “office of no” perception: Security has a negative reputation. Counteract it by being solution-oriented, connecting with people, and showing you are on their side.
- Train engineers in their language: Developers who care about code quality already care about security implicitly. Frame security as quality. Ask what prevents them from following guidelines rather than lecturing them.
- Use root cause analysis to drive change: When incidents occur, trace them back to process gaps. This creates evidence-based justification for controls rather than opinion-based mandates.
The fundamental principle: you cannot influence without a relationship. Building relationships takes time, transparency, and consistent demonstration of value. The security teams that succeed are the ones that stop throwing rocks from ivory towers and start building partnerships with the teams they are trying to help.
