Offensive Security Is a Reality Test

The purpose is not finding vulnerabilities; it is correcting what the organization believes about itself.

I have spent a lot of time thinking about what offensive security is actually for. In my first post, I wrote about intuition-driven offensive security and the operating principles I have come to believe matter most: developing a deep understanding of the target, getting to the technical truth, and hunting for critical risk. More recently, I wrote about protecting that work from the steady stream of seemingly reasonable requests that can slowly turn an offensive security team into something else. Those focused on the work itself, but the longer I have led this kind of function, the less satisfied I have become with answers that describe what offensive security does without explaining why an organization needs it.

The obvious answers are not wrong. Offensive security finds vulnerabilities, tests controls, follows attack paths, emulates adversaries, and helps improve defenses. I have used all of those explanations myself, and depending on the audience, I probably will again. But some of the most consequential work I have seen was important for a different reason: learning that something the organization believed to be true was not.

All too often I have seen environments where everyone accepted a critical security boundary was present because it had existed in the design or controls were functioning exactly as intended, when neither was still true. I have also seen systems considered relatively low risk until someone followed an attack path far enough to understand how they interacted with everything around them. In each case, the technical discovery was important, but the real impact came from correcting the organization’s understanding of itself. That distinction, between individual findings and discoveries that change how the organization understands itself, has become central to how I think about the purpose of offensive security.

Confidence Without Evidence

Large organizations develop beliefs about how they work, and most of those beliefs start somewhere reasonable. A team designs a boundary, implements a control, builds an architecture, or makes a risk decision based on the environment in front of them. Some of that understanding gets captured in diagrams, risk registers, control descriptions, and dashboards; some of it remains informal as tribal knowledge, embedded in the way people talk about systems and make decisions. At that point in time, the organization’s picture of itself may be largely accurate.

But systems keep changing. New products launch, services become interconnected, teams reorganize, acquisitions bring in technology designed under different assumptions, and temporary exceptions survive far longer than anyone expected. Controls are modified to solve operational problems, dependencies accumulate, and the environment gradually becomes something different from the one that was originally designed and reviewed. The organization’s understanding does not always change at the same speed, which is how a once-correct assumption can become a source of risk without anyone making an obviously bad decision.

I have always been interested in what happens after an assumption becomes established. A control operates for years without a known incident, a boundary is repeated in design reviews and conversations, or a risk rating is copied forward from one assessment to the next. Over time, the absence of contradictory evidence starts to feel like confirmation, even though nothing may have happened to test the original belief. Every year that a control goes unchallenged adds confidence without adding evidence. There is a meaningful difference between knowing that something works and simply having believed it for a long time.

I do not think this is primarily a problem of dishonesty or incompetence. In most cases, people are doing exactly what we would expect them to do inside a complicated organization: making decisions with incomplete information, relying on prior work, and simplifying an environment that no individual can understand in full. The problem is that those simplifications accumulate. Eventually, the organization can become very confident in a picture of itself that has not kept pace with the systems it is supposed to represent.

What Are We Actually Testing?

Suppose an offensive security team tests a trust boundary and finds a way around it. At the most immediate level, they found a vulnerability, and there will be a technical root cause, a severity discussion, and some form of remediation. Great! But what happens next? There also needs to be a more fundamental root-cause discussion: why were we confident the boundary would hold, where did that confidence come from, and was the original assumption wrong or did the environment change around it? (This needs to be no-fault and focus on process failures, not human failures.) If other decisions were made based on the same belief, fixing the individual vulnerability may solve the immediate problem while leaving a greater one in place.

This is why I think the most consequential discoveries are often moments where the organization learns something about its own reasoning. Why did we believe this path was not possible? What assumptions led us to treat one system as isolated from another? Did we misunderstand a control, or did we understand it correctly but fail to account for how it interacted with the rest of the environment? What compromises were made with valid point-in-time business justifications or risk acceptances, and do those justifications still hold? The vulnerability is evidence that something went wrong, but the assumptions behind it are usually the more interesting story because they tell us whether the same misunderstanding is likely to exist elsewhere.

The same reasoning applies when offensive work does not produce the dramatic result people expect. An attack path can fail because a control genuinely works, an architectural decision can hold up under scrutiny, or a detection can behave exactly as the team intended under realistic conditions. That result still adds something useful because confidence is now supported by evidence rather than habit. The objective is not to prove that the organization is insecure; it is to find out what is true and be willing to follow the evidence even when the answer is less exciting than expected.

That is what I meant when I wrote about getting to the technical truth as a core principle of intuition-driven offensive security. A penetration test can be useful, a red team operation can be useful, and vulnerability research can be useful, but the activity alone does not tell me whether the work mattered. I care much more about what we learned: whether an assumption changed, whether we generated evidence that altered our understanding of risk, or whether the environment behaved differently once someone stopped reasoning from the documented model and interacted with the system itself. When that happens, the work has done more than add another finding to a bug tracker.

Testing Reality, Not the Control

Most organizations already have many ways to reason about security. Architecture reviews examine designs, risk assessments help teams reason about likelihood and impact, compliance programs evaluate requirements, and control testing can produce evidence that specific safeguards are present and operating. Good security organizations need these functions, and I do not think offensive security replaces any of them. The distinction I find more useful is that most of these activities begin with some assumed model of the system, while offensive security can sometimes reveal that the model itself is incomplete.

A review can examine whether a documented boundary is well designed, but an attacker may not need to cross that boundary at all. A control assessment can determine whether a safeguard operates as defined, while two individually reasonable behaviors combine into an attack path nobody considered. A risk process can evaluate the risks the organization has identified, but it is weaker against the unknowns because nobody knew to ask about them. From my perspective, this is where offensive security is most valuable; not because it owns some special version of the truth, but because it can challenge the assumptions that determine what the rest of the organization chooses to focus on.

Offensive teams have their own blind spots, of course. They make bad assumptions, miss important things, and can become far too confident in clever technical results. A team built around technical truth should expect its own claims to survive scrutiny too, which is one reason I am wary of treating offensive security as inherently more objective than every other security discipline. The difference is approach and mindset: at its best, offensive security is given room to interact with systems as they actually exist, pursue unexpected behavior, and keep asking questions after the documented model says the answer should already be known.

This is also why I care so much about deep understanding and exploration. A shallow assessment is usually constrained by the same model everyone else is using: test the expected surfaces, look for familiar classes of problems, and report what you find. Sometimes that is exactly what is needed, but it is less likely to expose a foundational misunderstanding and critical risk. The more interesting discoveries often appear only after someone stays with the problem long enough or approaches it differently enough to realize that the original question was wrong.

The Executive Lens

All of this becomes more important as organizations grow because leadership cannot observe the environment directly. Executives cannot personally validate every architectural assumption, inspect every control, or understand every interaction between systems, and neither can the leaders below them. Information has to be compressed as it moves through an organization, so we build dashboards, track metrics, maintain risk registers, and summarize complicated technical realities into something that can support a decision. That compression is necessary; the problem is that leadership eventually has to make decisions based on it.

Where should we invest? Which risk deserves attention? Which problem has already been solved, and where are our false senses of security rooted? Every one of those decisions depends on some understanding of the environment, and the quality of the decision is constrained by the accuracy of that understanding. When the picture drifts, leadership can make perfectly rational decisions that are still wrong because the inputs no longer reflect how the organization and its products currently work.

This is where I think the purpose of offensive security shines. The best work gives the organization evidence that helps correct its understanding of risk, whether it confirms an investment is working, shows that confidence has outrun reality, or exposes a risk born of bad or incomplete assumptions. The technical finding is how we discovered the problem, but the more important outcome is that the organization now knows something it did not know before. For leadership, that means a better basis for deciding what to fix, what to fund, what to accept, and where confidence is justified.

Seen this way, the specific offensive security activities are mechanisms for generating evidence about how the environment behaves under adversarial pressure. I have been saying a version of this for years: the greatest value a red team provides is not the red teaming; it is knowing truths and advising from them. If the work does not improve the organization’s understanding of risk, I think we should be willing to ask whether the activity itself has become the goal.

A Truth Function

I increasingly think of offensive security as a truth function, although I use that phrase carefully. I do not mean that offensive security owns the truth or that every conclusion from an offensive team should be accepted without challenge. I mean that the function exists to compare what the organization believes against what can actually be demonstrated, then explain where the two differ. That can be uncomfortable work, but discomfort is not the objective; a more accurate understanding is.

The questions are usually straightforward even when the answers are not. Can that boundary be crossed? Does this control stop that attack for the reasons we think it does? Is the system really isolated? Will the attack path fail where everyone expects it to fail? Most importantly, are we confident because we have evidence, or because nothing has challenged the assumption yet? These questions matter to engineers and security teams, but their true value is broader because leadership is constantly making decisions under uncertainty.

That framing has changed how I think about this work. Finding vulnerabilities still matters, as do testing controls, researching products, emulating adversaries, and all of the other activities that fall under offensive security. I see those as mechanisms rather than the purpose; the purpose is to help the organization understand reality as it actually exists, especially when that reality is inconvenient, unexpected, or inconsistent with what everyone already believes. Attackers eventually get a vote in which assumptions survive contact; I would rather find out we were wrong from our own people first.