CTEM Validate Stage: Prove Exposures Are Real

• What validation proves and what it does not prove
• The safe validation methods and when each one fits
• The evidence standard that makes remediation teams act
• How validation changes priority, and how to record the outcome
• The metrics that show validation is working

Why validation exists

Discovery and prioritization produce a ranked list of suspicions. A scanner reports a vulnerable package version. A cloud posture tool reports a storage bucket policy. An identity tool reports a stale privileged account. None of those findings tell you whether an attacker standing outside your network, or inside a compromised workstation, could actually use them. Validation is the step that converts a suspicion into a fact, and a fact is what earns engineering time.

Programs that skip validation reliably produce the same failure: a very large backlog, a low fix rate, and eroding trust from the teams asked to do the fixing. Validation is the pressure valve.

The three validation questions

1. Reachability. Is there a real path from an attacker position to the asset? Internet exposed, reachable from a user subnet, reachable only from an isolated management network, or not reachable at all.
2. Exploitability. Given that position, does the weakness actually work? Is there a public exploit, a known technique, a required precondition that is or is not met?
3. Control effectiveness. Do the controls in the path block, degrade, or detect the technique? A working exploit that is blocked by a WAF rule and generates a high fidelity alert is a different risk from one that runs silently.

Validation methods and when to use them

The evidence standard

Weak evidence is the most common reason a validated exposure still does not get fixed. Every validation record should carry five fields:

• Position. Where the test was run from, in plain language, such as unauthenticated internet or a standard corporate laptop.
• Action. What was attempted, in one sentence.
• Result. What happened, including partial success.
• Control outcome. Blocked, not blocked, detected, not detected.
• Artifact. A timestamped log line, tool output, screenshot, or ticket reference.

Recording validation outcomes

Validation has four possible outcomes and each one changes what happens next. Record the outcome on the exposure record itself so prioritization can consume it in the next cycle.

How validation changes priority

Prioritization before validation is a hypothesis; prioritization after validation is a decision. A medium severity finding that is confirmed exploitable from the internet on a revenue system outranks a critical severity finding on an isolated host every time. Feed the validation result back into the Prioritize stage so the ranking reflects proof rather than vendor severity.

Safety rules for validation

• Agree the rules of engagement in writing before the first test.
• Prefer read only proof over anything that writes, deletes, or persists.
• Notify the SOC before tests that generate alerts, and confirm afterwards whether they fired.
• Never validate using real customer data as the test subject.
• Log every validation action so an auditor can reconstruct it.

Measuring the validation stage

• Percentage of prioritized exposures validated per cycle.
• False positive rate discovered by validation, tracked per discovery source.
• Percentage of validated exposures that controls blocked or detected.
• Median time from prioritization to validation.
• Revalidation rate after remediation, which should be one hundred percent.

• Pick the top ten prioritized exposures and define one validation method for each
• Write a one page rules of engagement covering what may and may not be tested
• Add the five evidence fields to your exposure register as required fields
• Run a first validation round and record the four outcome types
• Feed false positives back to the tool or team that produced them

• Treating a scanner severity score as validation
• Validating everything instead of the prioritized set
• Producing evidence that only the tester can interpret
• Testing in production without change approval or SOC awareness
• Never revalidating after a fix, so closure is self reported