Security culture is not built by mandates, tooling, or dashboards alone. It is built through relationships, empathy, and the deliberate accumulation of social capital. Ariel Shin, Product Security Team Lead at Twilio, started her career as a penetration tester before moving into application security specifically because she wanted to create visible, lasting change through developer relationships. In this episode, she shares how to find the right balance between speed and security, why empathy is a non-negotiable skill for security teams, and how to make vulnerability ownership a shared responsibility rather than a security-team-only burden.
You can read the complete transcript of the episode here >
How do you balance speed and security in DevSecOps?
Ariel frames this clearly: the fastest code review is no code review at all — but fastest does not mean best. The balance between speed and security is ultimately for engineering to determine and prioritize, with security acting as advisors.
- Use a maturity model approach: You cannot have everything at once. Set measurable short-term and long-term goals that scale with the organization’s readiness. Think of it like training for a marathon — trying to run 10 miles on day one leads to burnout.
- Acknowledge competing priorities: Security is not the only concern developers balance. Usability, performance, and feature delivery all compete for attention. Understanding those competing demands is the starting point for effective collaboration.
- Motivate through relationships, not just tooling: You can use carrots (rewards for doing the right thing), sticks (consequences for doing the wrong thing), or do nothing and hope for the best. The method that works most consistently is building relationships that make developers want to prioritize security.
This maturity-based approach mirrors what works in shifting security culture from friction to flow — meeting teams where they are rather than imposing an ideal state immediately.
Why is empathy the most important skill for security teams?
Empathy provides the context needed to motivate individuals to do the right thing. Without it, security becomes a flat list of findings with no business meaning.
- Vulnerabilities without context get ignored: If you prove a vulnerability exists but do not explain why it matters — in terms the audience cares about (revenue, brand, engineering productivity) — it becomes a non-issue to them.
- Remote work amplified the challenge: During and after the pandemic, people became flat screens. Personal lives bled into work lives, productivity dropped, and the question “why should I fix this security bug when the world feels like it’s ending?” became real. Empathy helps bridge that gap.
- It enables proper prioritization: Turning on a security tool that generates thousands of findings is easy. Deciding which findings actually matter to the organization, and communicating that effectively, requires understanding the developer’s context, workload, and constraints.
Ariel’s core principle: security is all about social capital. You build it through generosity with your time, through understanding what others are dealing with, and through showing up as human before showing up as security.
How do you build security culture in practice?
There is no single tool or framework for building culture. The approach must adapt to the audience and what motivates them.
- Lead with your power users: These are people who care about security without you even trying. They reach out on your first day, sing your praises, and give you honest feedback. Use them as amplifiers and feedback loops.
- Adapt your message to the organization’s incentives: If the company is sales-driven, explain how vulnerabilities affect revenue. If they care about brand image, frame risk in those terms. If they care about engineering productivity, show how incidents destroy it. Never assume security speaks for itself.
- Scale your influence beyond one-on-ones: Individual relationships are foundational, but they do not scale. Eventually you need to influence leadership’s thinking about security — and that requires translating security value into the language leadership uses to make decisions.
- Create space for human connection: Happy hours, informal one-on-ones, conversations that are not about security — these build the social capital you spend when you need a vulnerability prioritized or a tool adopted.
How should security training be structured?
One-size-fits-all compliance training checks a box. Effective training requires audience awareness.
- Broad audience (all employees): Keep the message simple. Phishing awareness, reporting processes, acceptable use basics. People click through; the goal is minimum viable awareness.
- Developer-specific training: This is where real impact happens. Ariel’s approach at Twilio Segment paired “think like an attacker” sessions with hands-on exercises (breaking the OWASP Juice Shop app), followed by walking through real threat models.
- Tailor to actual problems, not generic frameworks: Instead of teaching the OWASP Top 10 in isolation, pull from your bug bounty program to identify the top vulnerabilities your organization actually faces. Cater training to those specific issues.
- Create progressive levels: Once developers understand the basics of your threat modeling framework, offer advanced sessions rather than repeating introductory material every cycle.
The result is training that developers find genuinely useful rather than performative — which feeds back into the culture of taking security seriously across the secure development lifecycle.
How do you make vulnerability ownership a shared responsibility?
The worst model: security owns all risk. The better model: security is a partner, engineering is the owner.
- Standardize the process: Create a single, clear way for all individuals to interact with vulnerabilities. Developers should not need to understand the difference between cloud security, incident response, and product security teams to report or act on an issue.
- Democratize vulnerability management: The vulnerability belongs to the team whose code or infrastructure introduced it. Security partners with them to influence prioritization, but the decision and the action are theirs.
- Use social capital, not mandates: When you need an engineering leader to prioritize a vulnerability, that conversation goes very differently depending on whether you have an existing relationship. Dashboards and automated alerts are easy to mute. Relationships are not.
The honest truth Ariel shares: at some point in your career, a business decision will be made that compromises a security concern you felt was critical. That is normal. The response is not to fight harder — it is to invest more in influence, provide better context, and build the case more effectively over time.
How do you show security’s value to the business?
Ariel reframes security as an enabler, not a cost center.
- Tie risks to business impacts: Identify the top risks and explain how they materially affect the company — stock price, customer trust, engineering productivity, contract loss.
- Quantify where possible: At Twilio Segment, they tracked the dollar amount of contracts enabled by SOC 2 compliance and customer questionnaire responses. But measurement is a double-edged sword — over-quantifying can invite cost-cutting on things that do not show immediate dollar returns.
- Use external incidents as context: If your company has not experienced a breach, reference similar companies that have. Create a security Slack channel that shares post-incident analyses from peers in your industry. It makes the risk tangible without being alarmist.
- Balance metrics with relationship: Dashboards and KPIs matter, but they do not motivate action on their own. The relationships you build are what convert a data point into a prioritized work item.
How does Ariel rate common security practices?
- Training employees only during onboarding: Rated 2.5. At least you have training and a process for tracking who is trained. You are on the right path, but continuous reinforcement and audience-specific depth are needed to mature.
- Granting unrestricted cloud access for speed: Rated 2. Not ideal, but context matters. A 10-person startup focused on growth may reasonably accept this risk short-term while building a roadmap toward just-in-time access. Outline the risk, give leadership a plan, and mature as signals from customers demand it.
- No retrospective analysis after incidents: Rated 1 (worst). Retros are small, low-cost activities that compound into long-term cultural improvements. Skipping them signals that yesterday’s problems do not matter — which destroys the iterative improvement mindset security culture depends on. Retros also build humility and shared empathy when teams acknowledge what went wrong together.
