Scaling AppSec: Why Your Security Program Needs to Stop Being a Bottleneck

TLDR: Scaling application security in a high-growth environment requires moving away from top-down policy enforcement toward collaborative, embedded workflows. By treating security as the "glue" between engineering and platform teams, you can identify high-risk areas and automate remediation without stalling development. This panel discussion from BSides 2025 provides a blueprint for building these partnerships and measuring their impact through shared roadmaps.

Security teams often operate in a vacuum, pushing policies that developers view as friction rather than enablement. When you are the first security hire at a startup, or even when you are scaling a team at a mid-sized company, the traditional "gatekeeper" model fails. You cannot manually review every pull request or perform every threat model as the organization grows from 100 to 1,000 engineers. The reality is that if your security program isn't integrated into the developer's daily workflow, it will be bypassed.

Moving Beyond Policy Enforcement

The most effective way to scale security is to stop acting like an external auditor and start acting like a partner. This means embedding security into the platform itself. Instead of relying on manual checklists, you should be looking at how to automate security controls directly into the CI/CD pipeline.

During the panel, the speakers discussed the concept of "AppSec as Glue." This isn't just a metaphor; it’s a technical strategy. By building internal tools that provide immediate feedback to developers, you reduce the cognitive load required to write secure code. For example, using tools like Snow Alert allows teams to detect and alert on security anomalies in real-time, turning security into a data-driven process rather than a subjective one. When developers can see the security impact of their changes in their own dashboards, they are far more likely to prioritize those fixes.

The Engineering-Security Feedback Loop

One of the biggest mistakes security teams make is assuming that all developers have the same level of security awareness. They don't. The goal is to build a system where the "secure way" is also the "easy way." If you force a developer to jump through five different hoops to deploy a service, they will find a way around it.

A key technical takeaway from the discussion is the importance of shared roadmaps. If your security team is working on a project that doesn't align with the engineering team's quarterly goals, you are wasting your time. You need to identify the "security champions" within the engineering organization—the developers who already care about security—and give them the tools to influence their peers.

For instance, if you are managing cloud infrastructure, you should be working with the platform team to implement Infrastructure as Code (IaC) scanning early in the development lifecycle. By catching misconfigurations in Terraform or CloudFormation templates before they hit production, you eliminate the need for the "security gate" at the end of the process.

Measuring What Matters

How do you prove that your security partnerships are actually working? The panelists were clear: stop measuring the number of vulnerabilities found. That is a vanity metric that only encourages developers to hide issues. Instead, focus on metrics that demonstrate business value, such as the time it takes to remediate a critical vulnerability or the percentage of services that have adopted your security standards.

If you are building a platform, consider tools like Monocle to gain visibility into your environment. When you can show leadership that your security program is reducing the "blast radius" of potential incidents, you gain the political capital needed to secure more resources.

The Reality of Security Debt

Every organization has security debt, and you will never clear it all. The key is to be pragmatic. You need to prioritize the risks that actually matter to the business. If you are a B2C company, your biggest risk is likely data exfiltration or account takeover. If you are a B2B SaaS, it might be unauthorized access to customer data.

Don't try to fix everything at once. Pick one or two high-impact areas, build a partnership with the team responsible for those systems, and show them how your security tools can make their lives easier. When you help an engineering team ship a feature faster because your security automation caught a bug early, you have won.

What to Do Next

Stop writing long, unread security policies. Instead, go to your engineering team and ask them what their biggest pain point is when it comes to security. Is it the time it takes to get a PR reviewed? Is it the complexity of the cloud IAM policies? Is it the lack of visibility into their own logs?

Once you identify that pain point, build a solution that solves it for them. That is how you scale. That is how you become the "glue" that holds the organization together. Security is not a destination; it is a continuous process of building relationships and refining the tools that allow your developers to build securely by default. If you aren't already sitting in on your engineering team's sprint planning sessions, start there. You will learn more about your actual security posture in one hour of listening to developers than you will in a week of running automated scanners.