Reflections on my recent Security Champions Podcast episode with Ariel Shin
One of the things I admire most in security professionals is when they’re motivated not just by the thrill of breaking things, but by the responsibility of helping put them back together, stronger. That’s why my recent conversation with Ariel Shin struck me so deeply.
Ariel began her career as a penetration tester, sharpening her skills by uncovering the same kinds of vulnerabilities again and again. But instead of chasing the endless cycle of “find and report,” she felt pulled toward something different: becoming part of the solution. Her transition into application security was driven by a simple but powerful desire to work more closely with developers, understand their context, and collaborate on fixes that actually stick.
That shift, from breaker to problem solver, wasn’t just a career move. It was a mindset shift that reflects real empathy for the people writing code every day. And it sets the stage for a bigger conversation about how AppSec teams can and should work with engineering.
Ariel and I spent a lot of time discussing “glue work,” which is generally defined as the invisible connective tissue that holds teams together. Things like cleaning up documentation, facilitating cross-team collaboration, or just being the one who ensures the right people are talking to each other.
She shared how much she enjoys this kind of work, especially in leadership roles where acting as “glue” multiplied her team’s impact. But she also acknowledged the risk: glue work can be a career trap for early-career engineers who spend too much time on it and not enough time deepening their technical skills.
This conversation made me reflect on my own experience and perspective. As a junior developer, I did spend quite a bit of time on glue work because I saw opportunities to improve the efficiency of the entire team and process, ultimately leading to better outcomes, but at the sacrifice of some of my technical growth. I believe I eventually found the right balance, but this approach and the resulting lessons definitely served me well as an AppSec leader, where the value of glue work happens to be really important. Connecting siloed engineering teams, aligning developers with security, smoothing over friction, this is all part of the job. But Ariel also reminded me that, even in AppSec, glue work has to be intentional. For senior AppSec practitioners and architects, it can be transformative. For juniors, it can be costly if it comes at the expense of technical growth.
The challenge for leaders is to step into glue work where it adds cultural value, while protecting less experienced engineers from being consumed by it. This is a crucial balance.
We also dug into threat modeling, which has become both a buzzword and a burden in many organizations. Ariel was candid about the shortcomings she’s seen when leadership demands output metrics like how many models were completed, what percentage of the org was covered, and so forth, without understanding that the real value is qualitative.
Her view resonated with me. The magic of threat modeling isn’t in the number of tickets filed or checkboxes marked. It’s in design conversations and quick decisions where risky ideas get course-corrected before they ever ship. Those moments rarely show up in metrics but can quietly prevent the next headline incident.
The real measure of success, Ariel argued, is when engineering teams themselves recognize security as a partner in their success. When developers proactively invite us into their design discussions or give credit for helping them ship something securely, that’s when we know threat modeling is working.
One of Ariel’s strongest themes was the tension between scale and relationships. Automation and tooling are essential for coverage, but deep, trust-based relationships with developers are what make security culture stick.
She described AppSec as a toolbox: sometimes the right tool is automation, sometimes it’s embedding with a team to understand their constraints and co-create solutions. The art lies in knowing when to use which tool.
This made me pause. Too often we look for one-size-fits-all answers. Formalized programs, metrics dashboards, coverage maps. But in practice, building long-term affinities with certain teams, cultivating expertise in their domains, and consistently showing up as a trusted partner may be what tips the balance from compliance-driven to culture-driven security.
Perhaps the most important takeaway for me was Ariel’s approach to culture change. She described the reality developers face: pressure to ship quickly, while navigating mandatory reviews from security, legal, privacy, and more. They’re already overloaded.
Her philosophy is simple:
The emphasis on recognition is a powerful lever. Highlighting great security partnerships sets the tone for the rest of the organization. It tells developers that their input is valued, and that security isn’t here to slow you down or shame you, it’s here to grow with you.
My conversation with Ariel left me thinking differently about where I spend my own time as a security leader. Glue work, when done deliberately, can be one of the most impactful things we do... connecting dots, building trust, smoothing organizational friction. But it’s also work we must steward carefully, ensuring it doesn’t derail technical growth for those earlier in their careers.
Threat modeling, too, can’t be reduced to vanity metrics. Its power lies in the subtle course corrections and the relationships it builds, not just the artifacts it produces.
And ultimately, the path forward is cultural. Empathy for developers. Recognition for good security citizenship. Critical thinking about where our time and attention should go.
Ariel’s story reminds us that security isn’t just about breaking, it’s about building. It’s about being in it with our engineering partners, not standing outside pointing fingers. This is what builds trusting relationships that make security stick.
- Dustin Lehr