Vulnerability checks and real attacks have different goals, methods, and viewpoints. This difference leaves gaps. Let's look at six gaps repeatedly found in practice.

1. The checked scope and the actual attacker's scope are different.

Vulnerability checks have a fixed scope. Schedules are announced, target systems are agreed upon, and sensitive assets that could affect operations are often excluded. This is a reasonable choice for stable checks.

However, real attackers face no such limits. Forgotten legacy servers, systems handed over from outsourcing, temporary services, open ports—all become entry paths. In ENKI Whitehat's Red Team projects, the actual starting point of intrusion was often an asset completely outside the check's scope. Checks look where we show; attackers look where we forgot.

2. Checks are a "checklist," while attacks are a "scenario."

Vulnerability checks have inherent limits. They match the system against a list of known vulnerabilities and summarize the results.

Red Teams achieve goals instead of checking items. With goals like stealing customer data, accessing secrets, manipulating payments, or taking over servers, they replicate the tactics, techniques, and procedures (TTPs) of real attackers, combining low-risk vulnerabilities into one attack. Connecting small leaks, loose authorization, and unused open ports creates a path from outside to critical data. Checklists structurally fail to find this. Individual items were "Good" or "Low," but combined they became "Critical." This is the biggest difference.

3. Checks are point-in-time, while attacks are continuous.

Quarterly or bi-annual checks are inherently like a single snapshot. However, today's systems are deployed many times a day, and settings change slightly even during operation.

Updates and new assets during the long gaps between checks are effectively defenseless. The cycle of change is now in minutes, but verification remains quarterly or bi-annual. One API added or one firewall policy opened in a hurry after a check stays exposed for months. This gap is where critical vulnerabilities begin.

4. Checks only look at systems, not people and processes.

Vulnerability checks look at systems. However, real-world breaches often start with a phishing email, a neglected partner account, or social engineering that exploits trust.

Data backs this up. Global breach analysis reports repeatedly show that many breaches bypass systems via "people" through phishing, stolen credentials, or poor insider access controls. Yet, no secure coding guide flags this as "vulnerable." Red Teams verify by integrating people, processes, and systems into one attack surface.

5. They look at 'can we block,' but not 'can we detect.'

Vulnerability checks ask, "Is there a hole?" But the more critical question is, "Can we detect it when someone actually breaks in?"

Many companies block initial entry through checks. Yet once in, attackers move laterally, escalate privileges, and extract data while detection often fails. Taking hundreds of days to identify and respond reveals that organizations invest less in 'detecting' than 'blocking.' Often, as attackers roam for days, no security alert triggers. Verifying entry risk and detection capacity together is Red Teaming's core value.

6. The trap of peace of mind created by "Good Reports"

The last issue is organizational, not technical. Accumulating "Good" reports over years creates a false sense of security that "we are a well-checked company." The root cause is the direction of appraisal. As long as leadership asks, "Did we pass the checklist?" rather than "How severe were the vulnerabilities found?" the organization optimizes to get "Good" ratings rather than find risks. Vendors also lack incentive to present uncomfortable truths to maintain business relationships.

This is why Red Teams exist with an independent, adversarial viewpoint. Only verification judged by results, not relationships, reveals the real risks hidden in reports.