When I joined The Aspen Group as AppSec Lead, I inherited a classic enterprise security situation: five business units, each with their own engineering culture, their own tech stack, their own definition of "done," and their own relationship with security - ranging from adversarial to genuinely engaged.
The instinct in that situation is to reach for standardization. One scanner. One process. One policy. Push it everywhere.
That's the wrong instinct.
The Standardization Trap
Standardization feels like security leverage. If everyone runs the same SAST tool against the same pipeline gates, you get coverage and consistency. And you do - for the problems that scanner finds.
What you don't get: engagement. When security feels like an external force pushing friction into engineers' workflows, engineers route around it. They false-positive suppress. They push to later environments. They mark everything as "accepted risk" without understanding the risk. The scanner runs; security theater is performed; actual risk is unchanged.
The insight that reoriented my approach: the goal isn't to run a security process across five business units. It's to have five business units that make good security decisions. Those are very different objectives, and they require very different programs.
What Actually Works
Meet teams where they are. The first thing I did was spend time with each engineering team - not to audit them, but to understand what they were building, what their deployment pipeline looked like, what they cared about. You can't design effective controls without understanding the system you're protecting.
Identify the champions. In every engineering team, there's someone who cares about security - maybe they have a background in it, maybe they've been burned by a bug, maybe they just have good instincts. Find them. Invest in them. They're your force multiplier.
Right-size the ask. A startup-culture business unit that ships multiple times a day has different constraints than an enterprise team running quarterly release cycles. The same security control has different cost structures in each environment. Calibrate accordingly.
Move security left, but not all the way left. The "shift left" orthodoxy - put all security in development - ignores that most developers don't have the training or bandwidth to do security review well. The right model: lightweight automated checks in CI that developers can act on, with security engineer involvement at higher-risk decision points (architecture changes, new external surfaces, sensitive data handling).
Measure what matters. Mean time to remediate critical vulnerabilities. Percentage of new code shipped through secure SDLC touchpoints. Number of security-related incidents per quarter. Not "number of SAST scans run." Vanity metrics protect the security program's appearance of activity; impact metrics tell you whether you're actually reducing risk.
The Organizational Layer
The hardest part of enterprise AppSec isn't technical. It's getting security work prioritized in backlogs that are already overcommitted.
The lever that works: connect security work to business outcomes, not security outcomes. Not "we need to fix this injection vulnerability because OWASP says so," but "this vulnerability could allow an attacker to access customer data from other business units, which is a regulatory incident and a trust breach."
Executives respond to business risk. Engineers respond to concrete, actionable asks. Security programs that speak both languages outperform those that speak only one.
The Tooling Stack (Yes, It Matters)
I won't be prescriptive about specific tools because the right tool depends on your stack and your team's capabilities. But the architecture I've found effective:
- SAST integrated into CI, with suppression requiring documented justification (not just a click)
- SCA/dependency scanning with SBOM generation - increasingly important for compliance
- DAST on staging environments for externally-facing surfaces, not just dev
- Secrets scanning with pre-commit hooks and CI gates - this one pays immediate dividends
- Manual security review for high-risk changes, with clear criteria for what triggers it
The critical piece people miss: feedback loops. Every time a security tool surfaces a finding that leads to a real fix, that's a data point that security tooling produces value. Surface those stories to engineering leadership. Build the organizational narrative that security investment pays off.
Where This Goes
AppSec at scale is ultimately about building a security culture that doesn't require security team intervention for every decision. That takes years. The short-term work is controls and coverage; the long-term work is trust and education.
Two years in, the metric I'm most proud of isn't vulnerability counts. It's the number of times engineering teams proactively loop me into architecture decisions before they're committed to code.
That's the program working.
This post is adapted from a talk I gave internally at TAG. If you're building an enterprise AppSec program and want to compare approaches, reach out.