Most AppSec programs don't die in a dramatic incident. There's no postmortem, no all-hands, no moment where someone says "this is over." They just slowly stop mattering. Findings pile up in a queue no one is moving. Meetings get cancelled. Emails go unanswered. The scanner keeps running. Nobody's looking at it.
The failure mode isn't technical. It never was.
Every AppSec program begins with a set of assumptions, usually unstated. That engineering relationships built over years would make adoption smooth. That two or three quarters would be enough to get something fully functional. That objective data — a SAMM assessment, a risk register, scan results — would create alignment on its own. That if you let engineering pick the tooling, they'd own the adoption.
These assumptions aren't unreasonable. In a vacuum, they're logical. The problem is that AppSec doesn't operate in a vacuum. It operates inside an organization with existing power structures, competing priorities, and a very specific set of unspoken rules about who gets to tell engineers what to do.
The data doesn't create alignment. The relationships don't transfer automatically. And the tooling choice doesn't buy ownership — it just shifts where the blame lands when adoption fails.
The trust breakdown rarely announces itself. It happens in the gap between what you intended and how it was received. The table below is exact. I've lived every row of it.
| Built a custom scanner and published the results | → | "You went around us" |
| Automated rollout into repositories | → | Loss of autonomy == forced control |
| Generated hundreds of tickets overnight | → | An attack on engineering capacity |
| Enforced SLAs without prior collaboration | → | "Security creates problems, not solutions" |
Notice that none of those actions are wrong in isolation. A scanner that surfaces real vulnerabilities is doing its job. Automated rollout is operationally efficient. Tickets represent findings that need fixing. SLAs create accountability. Every one of those decisions was defensible on paper.
That's what makes this so hard to see from inside it. You're not making bad decisions. You're making good decisions at the wrong time, without the relationship infrastructure to absorb them. And the result is that every correct action is interpreted through the lens of an adversarial dynamic you didn't know had already formed.
Once trust breaks, the collapse doesn't look like a confrontation. It looks like nothing. Which makes it almost impossible to diagnose in real time.
It moves through three phases:
Silence. No opposition, no collaboration — just quiet. Meetings still happen. Slack messages still get a thumbs-up. Nobody is telling you anything is wrong. You interpret the quiet as acceptance. It isn't.
Deferment. "Later." "It's in the backlog." "We'll get to it." Every ask gets acknowledged and deprioritized. Nothing is explicitly refused. Everything is just... not now. This phase can run for months. It often does.
Isolation. Nobody announces it. Nobody sends a message that says you're being excluded. They just stop including you. The architecture review happens and you're not in the invite. The sprint planning doesn't have a security story. The RFC goes out without a security review tag. You find out about it afterward, if you find out at all.
By the time you're in phase three, the program is already over functionally. You're still showing up. The work is still technically happening. But you've been decoupled from the decisions that matter, and the path back is much harder than the path in was.
The rebuild — if you get there — looks different from the build. Here's what changes when you've learned it the hard way:
One problem at a time. The impulse when you're behind is to move on everything at once. Scan the whole estate. Fix all the critical findings. Stand up the full program. That impulse is correct from a risk perspective and disastrous from a trust perspective. Engineering has a finite capacity for security asks. When you flood that capacity, they start filtering — and your highest-priority items are not guaranteed to survive the filter. One problem, done well, with engineering's full attention, moves the needle more than ten problems spreading their attention thin.
Coverage ≠ progress. A finding count is not a risk metric. Tickets closed is not risk reduced. The question isn't how many things you found — it's whether the things you found are getting fixed, and whether the things that are getting fixed are the ones that actually matter. If you can't answer both of those questions, your program is producing activity, not outcomes.
If no one will use it, don't build it. This one took the longest to internalize. Every tool you deploy that doesn't get used is a trust withdrawal. It's a thing you asked engineering to care about that they decided not to care about, and now there's a JIRA project with 400 open tickets and no owner. Don't deploy tooling without adoption commitments secured in advance. If you can't get that commitment, the tool isn't ready to deploy — regardless of how good the tool is.
No trust? No tooling. The corollary to the above. Tooling is not how you build trust. It's how you operationalize trust that already exists. If the relationship isn't there yet, deploying a scanner doesn't accelerate it. It stress-tests it. And a relationship that hasn't been built yet will not survive that test.
This is the comparison I wish someone had handed me at the start:
| More tools, more scans | → | Less noise, more adoption |
| Security owns everything | → | Shared ownership or nothing |
| One AppSec engineer = program | → | One engineer = burnout |
| Velocity vs. security | → | Alignment before enforcement |
The right column isn't softer than the left. It's harder. Shared ownership is harder to build than sole ownership. Getting adoption is harder than deploying a tool. Alignment is harder than enforcement. But the right column is what actually works. The left column is what produces programs that run for three years and then quietly stop mattering.
These aren't abstract. They're the rules I run by now, on every engagement:
No surprises. No floods. No drive-by tools. Engineering gets visibility into what's coming before it arrives. If a scan is going to generate a hundred findings, that conversation happens before the scan runs — not after.
If I can't prove it's being used, it's noise. Every tool in the pipeline has to have demonstrable adoption. Not theoretical adoption. Not "they said they'd look at it." Actual triage activity, actual remediation, actual signal that the output is reaching a human who acts on it.
If I can't get buy-in before I build, I don't build. The program that exists on paper but not in practice isn't a program. It's a liability. Ungrown programs consume trust without producing outcomes. I'd rather not ship a capability than ship one that erodes the relationship I need to ship everything else.
One problem at a time — and finish it. The temptation to scope-creep a security program is constant. There's always another attack surface, another tool, another framework to adopt. The discipline is doing one thing, doing it well, making sure engineering trusts the outcome, and then moving to the next thing. Breadth without depth is just more noise.
If you're a solo AppSec engineer reading this, the most important thing I can tell you is this: you cannot save the company alone. The automation won't earn you the respect you need. No one is coming to rescue the program you built in isolation. The work you're doing matters, but the conditions you're doing it in may not be survivable indefinitely. That's not a reflection of your capability. It's a structural problem, and it needs a structural solution.
If you lead a security organization: one AppSec engineer is not a program. It's a liability. Budget that goes entirely to tools, with nothing left for the headcount that would actually make those tools useful, is not a security investment — it's a way to check a box while the underlying risk compounds. Praise without support is a resignation letter. That engineer knows it, even if they haven't said it yet.
If you lead an engineering organization: the security team's requests aren't blockers. They're guardrails. When we push back on a deployment, it's not because we want to slow you down. It's because your team is on call when it breaks, and we're trying to make sure it doesn't.
If you're an executive: try carrying risk with no headcount or runway for one quarter. You own velocity. We own blast radius. If you want to actually fix this — not fund it, fix it — you have to stay in the room long enough to hear the answer.
The programs that work aren't the ones with the most tools or the most findings or the most coverage. They're the ones where engineering actually trusts the signal — where a finding that comes through gets looked at instead of suppressed, where a security ask gets addressed instead of deferred, where the AppSec function is in the room when architecture decisions get made.
That trust is not a soft goal. It is the prerequisite for every hard goal. Without it, the scanner runs, the tickets pile up, and nothing actually gets fixed.
You can build a program that looks like a program from the outside. Dashboards. Metrics. Coverage numbers. Or you can build one that works. The difference is almost entirely in how much you invested in the relationships before you invested in the tooling.
Start there.