How does a four-person application security team protect all the code at a company the size of Lyft? The answer lies in a combination of risk alignment, secure-by-default engineering, and a deeply empathetic approach to working with developers.
We sat down with Anshuman Bhartiya, Staff Security Engineer and AppSec Tech Lead at Lyft, on the Scale to Zero podcast. Anshuman has spent over a decade in application security across companies like EMC, Intuit, and Atlassian, and is also the co-host of the Boring AppSec podcast.
You can read the complete transcript of the episode here >
What does product security actually mean?
The term “product security” means different things depending on the organization. At a healthcare startup like Thirty Madison, the “product” could be physical goods, a supply chain, or a technology platform. At Lyft, the product is primarily the app and its supporting services.
Anshuman defines product security broadly: securing everything from the point where things are being built to the point where they are served to customers. This spans application security practices like threat modeling and secure code reviews, all the way through to cloud infrastructure where services are deployed.
How do you unify risk across application and cloud vulnerabilities?
One of the biggest challenges in product security is building a unified risk framework. Application security vulnerabilities (like SQL injection) rarely have CVEs, while cloud security vulnerabilities in containers and third-party libraries do. Comparing and prioritizing across these fundamentally different types is difficult.
Without a well-functioning pipeline that funnels all vulnerabilities into one place for correlation, prioritization, and contextualization, organizations struggle to determine which issues to address first and what SLAs to set. Anshuman emphasizes that getting alignment on a risk framework from all stakeholders — from the CEO to engineering peers — is the essential first step before any prioritization can happen.
How does a four-person AppSec team scale at Lyft?
With only four AppSec engineers responsible for all of Lyft’s code, the team cannot be involved in every process. Their scaling strategy rests on three pillars:
- Focus on highest-risk areas: Identify which sub-teams and organizations bring the most risk, and concentrate efforts there.
- Secure-by-default frameworks: Understand the technology stack and build libraries that make the secure path the default path. Engineers use these frameworks without needing to think about whether their code is secure.
- Culture of proactive engagement: Engineers at Lyft reach out to the security team voluntarily — they do not view security as a blocker.
This approach lets the team reserve their intelligence for problems that genuinely require manual intervention, while automation and secure coding practices handle the rest.
What tools help reduce the burden on developers?
Beyond secure-by-default libraries, Lyft’s AppSec team integrates security controls as close to the developer workflow as possible:
- Git wrappers and pre-commit hooks: Scan code for secrets before it ever reaches the repository. Once a secret is committed, it is already too late.
- IDE plugins: Catch issues at the point of writing code, not after deployment.
- Integration with existing internal tools: Rather than building separate security systems that introduce friction, the team embeds checks into the platforms engineers already use daily.
The key insight: meet developers where they are. Nobody wants to learn a new tool. Embedding security into existing workflows through shift-left practices removes friction entirely.
How do you build a security culture rooted in empathy?
Anshuman’s approach to security culture starts with empathy. When joining a new company, he spends the first two to three months understanding the people, processes, and technology before proposing any changes. Building genuine relationships with engineering peers is non-negotiable.
His advice for building security culture:
- Understand developer pain points first. Learn their tools, their deployment processes, their daily frustrations.
- Frame security in terms of user impact. Engineers respond to “this allows attackers to access customer data” far better than abstract severity scores.
- Accept that security is a shared responsibility. The security team provides data, facts, and recommendations. The owning team ultimately decides whether to fix, mitigate, or accept the risk.
How should AppSec teams measure success?
Metrics in application security are notoriously difficult. Anshuman highlights three approaches:
- Eliminate vulnerability classes: If SQL injection or XSS keeps appearing, the root cause is not being addressed. A mature program should see each vulnerability class only once before building a systemic fix.
- Track mean time to detect (MTTD) and mean time to remediate (MTTR): These should trend downward over time.
- Measure adoption of secure-by-default libraries: Building frameworks is one thing — if teams are not using them, the investment is wasted. Track usage and adoption rates.
How is AI changing application security?
AI is accelerating code generation dramatically, which means defenders must keep pace. Anshuman sees two practical approaches:
- Up-level security skills with AI: Use LLMs to analyze PRDs and specification documents that previously took days to review manually. The initial AI-generated analysis saves hours and helps prioritize vulnerabilities based on business risk.
- Introduce proxy layers for AI traffic: Rather than blocking engineers from using AI tools, funnel AI-based traffic through a central point for visibility and observability. This enables security scanning without slowing anyone down.
The goal is not to stop engineers from shipping fast — it is to make security invisible and automatic within their workflow.
