The Myth of “Secure by Design”

I’ve talked with security leaders who believe their mobile apps are protected. They’re not wrong about what they’ve done—they’re wrong about what it protects against.

In recent conversations, I’ve heard three confident defenses:

“Our backend is architected correctly.”

They’ve implemented separation of concerns, layered API security, authentication at every step. They followed the playbook.

“Our vendor handles that.”

Many organizations—especially smaller banks, credit unions, and regional players—rely on white-label app providers. The logic goes: this vendor serves hundreds of institutions, so they must be doing something right. And if something goes wrong, it’s a bigger problem than just us.

“We’re not a target.”

Manufacturing companies, logistics firms, B2B players—they see themselves outside the blast radius. Ransomware and data theft are on their radar. A weaponized mobile app? Not so much.

Each of these positions is reasonable. And each misses the same thing.

The Attack They’re Not Thinking About

Secure-by-design practices focus on building apps without exploitable flaws—no buffer overflows, no hardcoded credentials, timely CVE patches. This is good work. It makes the attacker’s job harder.

But it assumes the attacker is outside trying to get in.

Here’s what that misses: the modified app attack.

Your app ships clean. It passes every security scan. It’s signed and distributed through official channels. Then a threat actor downloads it, reverse engineers it, and makes a small modification—maybe changing a single branch instruction. They repackage it and distribute it through unofficial channels, or trick users into installing it directly.

Now they have a trusted agent inside your perimeter.

Your backend can’t tell the difference. The API calls look legitimate. The authentication works. The traffic patterns are normal. Because it’s still your app—just with a small piece of malware along for the ride.

This isn’t a theoretical attack. It’s a documented, growing attack vector. And it passes right through the defenses those security leaders described to me.

Why the Blind Spot Persists

Traditional security thinking creates mental models that are hard to shake. If you’ve spent your career defending perimeters, hardening servers, and patching vulnerabilities, you think in terms of outside threats trying to breach your walls.

The modified app attack doesn’t breach your walls. It walks through the front door wearing your uniform.

Secure coding practices don’t prevent it—the original code was secure. Backend architecture doesn’t catch it—the requests are coming from what looks like your legitimate app. And your vendor can’t save you—they’re solving the same problem you are, at scale, with the same blind spot.

The CYA Problem

There’s another dynamic at play. In some of my conversations, I sensed that security leaders had made peace with a certain kind of risk—as long as the blame could land somewhere else.

If your white-label vendor gets breached, that’s their problem. You’re a casualty, not a cause. If the attack vector was something nobody in your industry was defending against, you’re not negligent—you’re normal.

This is rational career preservation. But it’s not security.

The uncomfortable truth is that “nobody else is doing it either” stops being a defense the moment you’re the one explaining the breach to your board.

The Question Worth Asking

I’m not here to tell anyone their security program is wrong. Defense in depth, secure coding, API hardening—these are real and necessary.

But I’d ask this: what’s your plan for the attack that uses your own app against you?

If the answer is “we’d detect it on the backend,” I’d push back. You might detect anomalies eventually. But by then, the damage is done—credentials harvested, sessions hijacked, fraud committed.

If the answer is “that’s not a realistic threat for us,” I’d ask what’s informing that confidence. The attack tooling is commoditized. The techniques are documented. The targets are expanding beyond financial services.

And if the answer is “that’s someone else’s problem,” I’d just ask: is it?