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.

Why Your Incrementally Funded Program Keeps Missing Milestones

The probability is high that no one will say this to you directly, so we will.

Your program isn't missing milestones because the team is slow. It's missing milestones because of systemic issues, not personnel issues. Especially if your funding is arriving in chunks too small to sustain continuous progress. Because there is a high likelihood your schedule was built as if that wasn't going to happen.

That's not your team's failure. That's system problem… an architecture failure. And it was baked in before the first task order was signed.

How Incremental Funding Actually Works in Practice

In theory, incremental funding is a budgeting mechanism. The government obligates money in pieces as it becomes available, rather than all at once at contract award. Makes sense from an appropriations standpoint. The problem is that the schedule (and the performance expectations attached to it) doesn't adjust to reflect how the money actually arrives.

So, here's what happens in practice:

Funding arrives. Work accelerates. The team makes real progress. Then funding runs out before the next increment is authorized. Work slows or stops. The team shifts to other things, or just waits. Three weeks later the next increment arrives and the team has to rebuild momentum — context has been lost, threads have been dropped, and the schedule clock kept running the entire time.

Repeat this cycle four or five times over the course of a year and you have a program that looks chronically behind, a team that looks like it can't execute, and a contracting officer who is frustrated that milestones keep slipping.

Nobody in that picture is wrong, exactly. But nobody is naming the actual cause either.

What The Contracting Office Won't Tell You

The funding gaps are a known variable on their end. They understand the appropriations cycle. They know when increments are likely to be authorized. What they often don't do is connect that knowledge to your schedule in any explicit way — because that would require acknowledging that the schedule as written isn't executable given the funding pattern as planned.

That's an uncomfortable conversation. So, it usually doesn't happen!

What happens instead is that your program gets evaluated against a schedule that was built assuming continuous funding, while operating on funding that is anything but continuous. The gaps are invisible in the performance data because nobody coded them as funding gaps — they just show up as slippage.

And slippage, in most government programs, gets attributed to the contractor.

What You Can Do About It

You can't control when funding arrives. But you can control how your program is structured to absorb the gaps — and how clearly you're documenting the relationship between funding events and schedule performance.

Try to build funding contingencies into the schedule explicitly. Every increment authorization is a schedule event. Treat it that way. When an increment is delayed by two weeks, the schedule impact of that delay should be visible, documented, and communicated — not absorbed silently and blamed on execution later.

Work to establish a clear record of work authorization dates versus schedule baseline. If your contract says a milestone is due on a specific date and the funding that enables that milestone didn't arrive until three weeks before — that's not a missed milestone, that's a schedule that needed to be adjusted. Document it at the time, not after the fact.

Push to have the funding conversation with your prime and your KO/COR at program kickoff, not after the first gap. Ask directly: what is the anticipated funding profile? How does that align with the schedule? What is the process for adjusting the schedule if funding is delayed? Getting those answers on record changes the dynamic when gaps inevitably happen.

Incremental funding isn't going away. It's structural to how the government spends money and there's nothing you can do about that.

What you can do is stop building programs as if it isn't happening — and stop accepting schedule evaluations that don't account for it.

Your program isn't behind. Your schedule just wasn't built for the reality it was going to operate in.

That's fixable. But only if someone is willing to say it out loud.

‍ ‍

At Leitwolf, we help technical teams build the right structure for the environment they're actually operating in — not the idealized version. If your program keeps slipping for reasons that feel outside your control, let's talk.

‍ ‍

You Didn’t Ask for It. That’s Not the Point.

Think about the last time you sat across from a doctor, an accountant, or a lawyer.

Did you hand them a checklist? Did you specify every standard they were expected to meet or every protection you were expecting them to apply? Because you are a normal human, we’ll just assume that you trusted them to do their job in the way a normal human would... Not blindly — but reasonably. Because the entire basis of that type of relationship is that the person providing the service knows things you don’t, and that their level of professional knowledge comes with an obligation to act in your interest.

Nobody tells their doctor “please wash your hands before you examine me.” The doctor just does it because it is good for his/her patient. Nobody tells their accountant “don’t share my financial records.” The accountant just protects their clients information to prevent strangers from getting it. Those things don’t get stated because they don’t need to be stated. They are so fundamental to the relationship that requiring them to be explicitly requested would be absurd.

That is what an implied requirement looks like when it works.

The question worth asking is what it looks like when it doesn’t.

When the Knowledge Gap Becomes a Shield

In technical program work, there is a defense that shows up with uncomfortable regularity. It sounds like this: “You didn’t ask for that.”

This stunning gem of professional failure is typically deployed at delivery time (a.k.a. the end of the project). When the gap between what was needed and what was built becomes impossible to ignore or hide in performance metrics. And it is technically true often enough to be very dangerous. The EXACT requirement wasn’t written down. It wasn’t in the contract. It wasn’t specified in language that could be pointed to.

What this BS argument leaves out is the reason WHY it wasn’t specified. The person who needed it didn’t have the technical knowledge to specify it in the first place. They came to a specialist. They trusted that the specialist would apply their expertise in the interest of the person they were serving, not just to the exact boundary of what was written down.

They trusted the implied requirement that you would build it the way that it should be built. Using that knowledge gap as a contractual defense is not a neutral act. It is a betrayal of the relationship that created the gap in the first place.

A doctor who says “you didn’t ask me to wash my hands” is not making a legal argument. They’re admitting they understood they had an obligation and chose not to honor it. The excuse doesn’t save them. It condemns them.

The same logic applies to all these types of situations. It just gets applied less consistently outside of medicine and law.

Security Is Where This Cuts Deepest

Of all the places implied requirements live, security is a field where the consequences of not meeting them are the most serious.

The person commissioning a system (any kind of a government program, a procurement, a contracted capability) often does not have the technical depth to specify every security control they need. That is not negligence. That is the nature of the problem. Security is complex, evolving, and deeply specialized. The entire reason you bring in experts is because you cannot navigate it alone. So, the person commissioning the work has a valid expectation of professionalism from the technical experts they hire!

When those ‘security’ experts deliver a system without encryption, without access controls, without audit logging, without the protections that any reasonable person would assume were included, they are not just defending their delivery… When they point to the requirements document and say: ‘it wasn’t specified’, they aren’t making a false claim ‘legally’ speaking... What they are doing is exposing the gap between what they were hired to do and what they chose to do.

The person who bought the house didn’t ask for locks. They assumed locks. Because a house without locks is not a house. It is a structure that fails at one of its most fundamental purposes. A system without security is the same thing. It is a capability that fails the moment it encounters the condition it was built to operate in.

And unlike a poorly specified feature that wastes budget and frustrates users, a security gap does not stay contained. It exposes data. It enables breaches. It causes harm to people who had no part in the requirements conversation and no ability to protect themselves from its outcome.

The stakes are not abstract. The knowledge gap is not theoretical. And the “you didn’t ask” defense, in a security context, is not a contractual position. It’s a confession.

What Professional Obligation Actually Means

Medicine codified this a long time ago. Informed consent. Do no harm. Finance/financial advising did too, using terms like fiduciary duty. These are not aspirational statements. They are enforceable obligations that exist precisely because the knowledge gap between specialist and client is real, significant, and consequential. And because supposed experts didn’t voluntarily meet those expectations.

They exist because the bodies who govern and regulate those fields recognized that leaving the implied requirements to chance produced outcomes that were indefensible. So, the obligations were made explicit. The professional is required to act in the client’s interest even when the client doesn’t know enough to demand it.

Technical program work, and security specifically, has not fully made that turn. Current contractual models still allow the knowledge gap to be treated as the client’s problem. If you didn’t write it down, you didn’t ask for it. If you didn’t ask for it, you don’t get it. If something goes wrong because of what wasn’t specified, that’s a requirements failure, not a delivery failure.

That model protects the wrong party.

The specialist has the knowledge. The specialist has the expertise to know what should have been in the requirements even when the client didn’t. The specialist took on the work knowing that gap existed. The obligation to close it — or at minimum to surface it explicitly rather than silently benefit from it — sits with the person who understood what was missing.

Implied requirements are not a loophole. They are a test of whether the expertise being sold is actually being applied in the interests of the person/people who needed it.

The Question That Has to Be Asked

Every program, at every stage, involves people who know more than the people they are serving. That asymmetry is not a problem. It is the point. It is why expertise was brought in.

What matters is what that asymmetry obligates.

Before delivery, someone with technical depth needs to be asking: what did this customer need that they didn’t know to ask for? What have we assumed they understood that they almost certainly didn’t? What gaps exist between what was specified and what is actually required for this thing to work safely, securely, and in the interest of the people it was built to serve?

Those questions are not scope creep. They are professional responsibility. And depending on the customers and/or products involved, could literally be a matter of life or death.

The customer hired you because the subject matter was too complex to navigate alone. They trusted that the expertise they were paying for would be applied in their interest — not just to the edges of what they were able to articulate.

The knowledge gap is the reason they hired you.

It was never meant to be a defense.

At Leitwolf, we treat implied requirements as real requirements — because the people we serve are counting on us to know what they couldn’t have known to ask for. If that’s the kind of partnership your program needs, let’s talk! Contact us: info@leitwolf.net