AppSec as Glue (Panel)

AppSec as Glue: Building Partnerships to Scale Security

Speakers: Sarah Liu (moderator), Ariel Shin, Jacob Salassi, Mukund Sarma, Tad Whitaker

Conference: BSidesSF 2025 — April 26-27, 2025, San Francisco

YouTube: Watch on YouTube

Reading time: ~8 minutes

TL;DR

Application security teams cannot scale through individual heroics alone — they scale by acting as organizational glue, building relationships with engineering, platform, detection, and business teams that multiply their reach. The panel's central lesson: AppSec's unique value isn't finding vulnerabilities; it's connecting the people and systems needed to fix them, fund them, and prevent the next generation of them entirely.

Introduction

The title "AppSec as Glue" could easily sound like a consolation prize — as if the security team's job is merely to hold other people's work together. The five practitioners who took the stage at BSidesSF 2025 for this panel reframed the metaphor entirely. Glue, they argued, is what makes everything else structurally sound. Without it, a program collapses under its own weight regardless of how good the individual components are.

Moderator Sarah Liu — who runs pentesting and bug bounty programs at Twilio — opened by polling the room: roughly a third to half of attendees came from pre-IPO startups, a significant share identified as AppSec practitioners, and a meaningful contingent attended specifically to understand how to build partnerships with AppSec. That audience mix made the panel's grounded, experience-first approach particularly well-timed.

The panelists brought complementary vantages. Ariel Shin leads an AppSec team focused on threat modeling, developer security training, and risk scoring, having previously led AppSec at Twilio. Jacob Salassi led product security at Snowflake for five years through 10x engineering growth before moving into startup work. Mukund Sarma leads product security at Chime. Tad Whitaker is staff product security engineer at Engine.com, former first security hire at CircleCI, and co-founder of the Day of Security initiative.

What "Glue" Actually Means in Practice

▶ Watch: Defining the glue metaphor (05:30)

Each panelist had a distinct angle on what organizational glue looks like day-to-day. Ariel Shin described it as leveraging soft power and political capital to get security work done without resorting to policy mandates. "Security teams can be siloed from one another and also siloed from engineering," she said, "and AppSec teams are one of those teams that can act as that glue and can become the face of security for many folks who don't often interact with security."

Jacob Salassi took a broader organizational view. Every company has dysfunction, he observed, and security practitioners are uniquely positioned to witness it — which creates an opportunity. "You're in a position to leverage remediating organizational dysfunction as a way to gain political capital," he said, "not in a perverse way — your help in bringing the business together is ultimately key to your success."

Tad Whitaker, speaking from exclusively pre-IPO experience, described glue as beginning with listening. When he joins a new organization, his first move is to find out what's already there — what tools exist, which ones are actually valued, which ones nobody would miss. "It really starts with me being a listener and trying to insert myself into wants and needs that exist and trying to create some cohesion there."

Mukund Sarma added that glue works in both directions. Engineering teams can also act as glue for the security program. The AppSec function he envisions isn't just finding a vulnerability but taking it all the way through: can we build a quick library? Can we introduce something that makes it easier for teams to onboard to a safer pattern?

Who to Partner With First — and How That Changes at Scale

▶ Watch: First partnerships and scaling dynamics (15:00)

A recurring theme was that partnership priorities depend heavily on company stage. Mukund Sarma, having spent his career at fintech companies, begins by building relationships with DevOps and the teams maintaining shared frameworks. "If you can amplify your impact not just for one team but to all the teams that are using the same underlying infrastructure or frameworks, that's the kind of way I've approached it."

Tad Whitaker's entry point is the chief architect — the person whose sign-off controls what ships. "Nothing happens without that guy," he noted about his current role. Getting alignment with that individual on priorities (bug bounty, no bug bounty, what the money is actually spent on) comes before almost everything else.

Ariel Shin surfaced the concept of the "unlikely champion" — an engineering team member who, without being asked, goes far beyond what was expected of a security partner. On a centralized vulnerability management project that touched all of engineering, a developer she called "Bob" independently built dashboards not just for his own team but for all of engineering. "He had catered it for engineering and became our engineering voice. And we didn't even have to ask him."

Jacob Salassi described the arc of developer security expectations as scale increases. At 100–300 engineers, it's good to be hands-on. At 300–500, it's valuable to get every developer doing something. But above 500, the math breaks down. "It's actually not a great idea to ask developers to know more and more security. You have to stop teaching them security and start delivering security in..." — in the platform. "You have to bake it into the platform. And if you're not able to do that, you're going to struggle to scale teaching a thousand people." He estimates that arc peaks around 500 engineers, and that three to five hundred is when teams should already be thinking about what the next generation of their security program looks like.

Secure Defaults: The Hard Road to Platform Integration

▶ Watch: Secure defaults and platform challenges (28:00)

The panel's most technically substantive exchange centered on secure defaults — the aspiration to bake secure behavior directly into the platforms engineers use, rather than asking them to remember rules. This is fashionable as a concept but notoriously hard in practice.

Jacob Salassi identified two paths. Either AppSec influences the platform team's roadmap — meaning a joint roadmap where AppSec's priorities appear in quarterly plans — or AppSec hires actual software engineers and infrastructure engineers capable of shipping production code. The middle ground is dangerous: "They're not really software engineers, but they're smart and they can hack stuff together. It's not a good idea to predicate secure defaults on that."

Mukund Sarma offered a concrete example of how long the road really is: a service authentication and authorization platform at his prior company took three to three and a half years to build and roll out. The work had buy-in from engineering and from platform teams. But getting to secure default requires handling multiple languages, different tech stacks, and edge cases that multiply over time. "Security defaults should not be looked at as a complete binary — like it's there or not there. I think it's a whole journey."

Tad Whitaker's approach is simpler by design. He focuses on two things immediately: hardening GitHub access and branch protection, and then hardening whichever cloud provider the company uses. Both areas reliably surface existing wants and needs that he can use to build credibility. He also mentioned a less glamorous tactic: turning off tools that nobody needs. "I tend to go in and turn off a lot of stuff and just quit paying those bills."

Ariel Shin, who is currently rolling out a secure defaults program, noted the importance of platform teams as the vehicle for adoption. Her team focuses on getting feedback on platform features and asking whether 100% adoption is even the right goal — or whether other opportunities might drive down risk more sustainably.

Partnering Across Security Teams — and Crossing the Aisle to Business

▶ Watch: Cross-team security partnerships (40:00)

Security teams themselves are siloed, and the panel spent considerable time on AppSec's relationship with threat detection, incident response, and red teams. Jacob Salassi described the problem as an information gap: "TDIR, red team — they sit over here and product sits over here. The people in TDIR have some idea of shadows on the wall about what happens in product, but they don't have any direct knowledge of it. And so that heavily impacts the quality of detections that get written."

His solution was to formalize a process that pulls all stakeholders in for strategic features — a system where every major threat model automatically produces not just risk assessments but a concrete question: what detection needs to be written for this feature? "How are we going to get the response plans written, and what is the red team going to do on purpose?" was the framing he used to structure the cross-team program.

Ariel Shin observed a cultural challenge that maps onto any attempt at cross-team collaboration: "AppSec people want to hop on a call. They're super friendly. They want to chat. Threat detection teams are like, 'No, back room only. We do not want to be on those calls with you.'" Recognizing that different teams communicate differently — and building processes that accommodate each — turned out to be as important as the technical integration itself.

Jacob Salassi also offered the panel's most counterintuitive partnership story: internal audit. Security teams often treat internal audit as an adversary. His former CISO's advice was the opposite: "Whoever you perceive as your enemy, that's who you have to bring in." Rather than waiting for audit to find problems and report them upward, Salassi's team at Snowflake began feeding internal audit their own priority list — essentially using audit's organizational authority (reporting directly to the CFO) as a "flaming sword" to drive remediation of things security couldn't get traction on alone.

Notable Quotes

"Security is often in a position to witness organizational dysfunction and be inhibited by it — which then leads to: you're in a position to leverage remediating that dysfunction as a way to gain political capital." — Jacob Salassi (08:00)

"At some point you have to stop teaching developers security and start delivering security in the platform. If you're not able to do that, you're going to struggle to scale teaching a thousand people." — Jacob Salassi (22:00)

"Security defaults should not be looked at as a complete binary — like it's there or not there. It's a whole journey, and there are a lot of smaller things you can start doing that will have a lot more impact while you work on those bigger ones." — Mukund Sarma (32:00)

Key Takeaways

• Glue means amplifying, not just advising. AppSec's leverage comes from its position at the intersection of engineering, platform, detection, and business teams — and that leverage disappears if the team operates in isolation.
• Partnership priorities should match the company's growth stage. Below ~500 engineers, developer education and hands-on involvement work. Above that, security must be delivered through the platform, not taught to individuals.
• Secure defaults require either a genuine joint roadmap or a real software engineering capability. Half-measures — smart-but-not-software-engineer AppSec staff hacking together platform components — do not scale and create technical debt.
• Internal audit is an underused ally. By proactively feeding audit the security team's priorities, AppSec can access organizational authority it otherwise couldn't reach.
• Cross-team communication requires style-matching. AppSec and threat detection teams operate with very different cultures; building processes that accommodate both — rather than assuming everyone will adapt to AppSec's preferred mode — is essential for programs like threat modeling to actually produce detections.