You Can't Protect What You Don't Understand

Ask a program team where their system is vulnerable and you'll usually get one of two answers.

The first is a compliance answer: here are our scan results, here's our controls matrix, here's the checklist and here's the evidence that we met it. The second is a shrug dressed up in professional language: the threat environment is complex, the adversary is sophisticated, nobody can predict everything.

Both answers have something in common. Neither one requires actual understanding of the system. In fact, either one is usually proof that the understanding isn't there.

And that's the problem. Because vulnerability isn't a property of checklists or threat environments. It's a property of the system itself. Of how it actually works, what it actually depends on, and — most importantly — where its actual behavior has quietly drifted away from what everyone believes about it. The more complicated a system gets, the harder it is for any one person or team to be the source of truth for it.

The Map Everyone Is Using Isn't The Right One

Every system of any age has two versions of itself.

There's the documented version — the architecture diagrams, the interface specs, the data flow descriptions written at design time and updated occasionally when someone remembers. And there's the real version — the one running in production, shaped by years of patches, workarounds, deferred decisions, inherited components, and integrations nobody fully scoped.

Those two versions are never the same. The gap between them grows over time, and it grows fastest in exactly the places nobody is looking. I want to say this clearly, so bear with me: THE SYSTEM ON PAPER IS ALMOST ALWAYS THE ONE SECURITY GETS MEASURED AGAINST!

Here's what matters: the vulnerable bits live in that gap. Not in the documented system — that's the version that got reviewed, tested, and assessed. Your ACTUAL system is where the vulnerabilities exist.

That sounds obvious... I get it. But what I'm telling you is not. I have done this a long time, and I can tell you there is a difference between ‘deniable’ and ‘non-existent’.

Most vulnerabilities live in the lane of deniability. In the undocumented delta. The dependency nobody wrote down. The trust relationship that was supposed to be temporary. The interface that behaves differently than its spec because the spec was wrong and fixing the code was faster than fixing the paper.

When an assessment is run against the documented system, it produces confidence about a system that doesn't exist. And people do it anyway — not because it makes their systems safer or protects their customers, but because it gives them plausible deniability when the failure finally surfaces.

Where the Vulnerable Bits Actually Are

After enough programs, the pattern becomes predictable. The weak points aren't random. They cluster in specific places — and every one of them is a place where understanding runs out. This matters for a very practical reason: knowing where they cluster tells you where the smallest amount of money fixes the most risk.

Vulnerabilities cluster at boundaries. Interfaces between components, between systems, between organizations. Boundaries are where two different mental models meet, and each side assumes the other side handled it. Authentication assumed on one side, performed on neither. Input validated "upstream" by an upstream that validates nothing. The boundary itself is fine on paper — the assumption embedded in it is the vulnerability.

They cluster around inherited pieces. The library, the legacy component, the code from a previous contract that "already works." Inherited pieces arrive with inherited assumptions that nobody on the current team made — and therefore nobody on the current team is watching. They cluster at the parts nobody owns. Every system has components that sit between responsibilities — maintained by whoever touched them last, understood by someone who left two years ago. Ownership gaps are understanding gaps, and understanding gaps are where problems live undisturbed.

And they cluster around whatever is load-bearing but invisible. Every system has a small set of things that everything else silently depends on — a service, an assumption, a single data source, one person's knowledge. Nobody thinks about them because they've never failed. That's exactly why nobody has ever examined what happens when they do.

Why the Checklist Can't Find Them

None of this is an argument against checklists, frameworks, or scans. But let's be honest about what a checklist actually is: a reminder of best practices. Lane markings. It tells you to keep it between the lines. It does not check whether you did.

And it cannot fill the gaps where you didn't. A checklist describes systems in general — the weaknesses common enough that somebody wrote them down for everybody. Whether any of that applies to your system, and whether your system actually complies with any of it, are separate questions the checklist will never answer. Worrying about the checklist before understanding the system is like worrying about food allergies before you've set the menu. You're assessing a restaurant that doesn't exist yet.

But that's exactly what most programs do. They assess the design. They review the documentation. They complete the checklist, document the completion, and hold the documentation up as evidence of security. "We evaluated the design" — I've heard it more times than I can count, and I'll say plainly what nobody else will: not good enough. That's not an assessment of your security. That's an assessment of a description of your security, filed in advance for the day something goes wrong.

Two reasons drive it, and only one gets said out loud. The stated reason is cost — everyone assumes a real assessment is a million-dollar fiasco nobody budgeted for. The unstated reason is cover.

Here's what my experience actually shows: THE MILLION-DOLLAR ASSESSMENT IS THE PRETEND ONE.

A real assessment is a competent engineer sitting with the system as it actually runs — tracing what really depends on what, asking of every component what has to be true for this to work, and then checking whether it's actually true rather than assumed. The output is short and usable: here are the gaps, and here is the cheapest way to close each one. That's the whole deliverable. It costs less than the compliance theater, and it's the only version that makes the system safer instead of the file thicker.

It's just harder to fake.

The Question That Finds the Weak Points

The most useful question isn't "what would an attacker do?" It's earlier and simpler than that. “What does everyone believe about this system that nobody has verified?”

Every unverified belief is a candidate vulnerability. Not because the belief is necessarily wrong — most of them are fine. But the ones that are wrong are wrong silently, and they stay wrong until someone finds them. Trust me when I say: you'd prefer that someone be you.

A system is exactly as defensible as it is understood. Not as defensible as its documentation. Not as defensible as its compliance posture. As defensible as someone's actual, current, verified understanding of how it works.

If nobody on your program can draw the real system from memory, then nobody on your program knows where the vulnerable bits are.

Someone else might find them first.

At Leitwolf, building an accurate understanding of the system as it actually exists — before assessing it, extending it, or defending it — is where we start. If you're not sure the system you're defending is the system you're running, let's talk.