Home/Blog/Proof before remediation

HAYROK LABS RESEARCH NOTE HL-RN-2026-02

How to prove a security finding is exploitable before remediation

No proof, no ticket. A remediation model engineering will actually trust, with the proof package and SLA policy to make it real.

Nov 2, 2026 @Melly 8 min read

TL;DR

No team can patch everything in the first week. Even the best performers in the 2026 DBIR fixed only 30% to 40% of known exploited vulnerabilities in seven days.

So stop sending engineering severity scores. Send proof: a verdict, the trigger that fired, the controls it passed and what it reaches.

Further down you will find a real proof package and an SLA policy written as code, ready to adapt to your ticketing system.

Most remediation programs hand engineering a severity score and a deadline, then hope for the best. This note argues for a different deal: no critical ticket leaves security without proof that the finding is exploitable in the target environment. We will walk through the proof package each ticket should carry, a tiered SLA model keyed to validated verdicts, and a retest step that closes the loop. The result is a smaller urgent queue, faster fixes where they count, and evidence for auditors instead of attestations.

Key findings

KEV FULLY REMEDIATED, 2025

26%

Down from 38%. Median time to full resolution rose from 32 to 43 days, with 50% more criticals to patch than a year earlier.

KEV STILL OPEN AT DAY 7

60–70%

Across more than 1 billion records. 35% were still open at day 28.

FIXABLE BY PATCHING ALONE

~10%

Of privilege escalation and credential access techniques. Privilege management covers about 65%, configuration 33%.

VALIDATION INSIDE CTEM BY 2029

60%

Of organizations, per Gartner's Market Guide for Adversarial Exposure Validation, published 24 March 2026.

So what does that add up to? Engineering time is the scarcest resource in the program, and nobody fixes everything in the first week.

You cannot outpatch attackers. You can decide which fixes go first, and proof is how you decide.

Why remediation without proof fails

Severity-driven remediation tends to break in the same four ways. You will probably recognise at least one.

It floods the urgent queue

When every CVSS 9 is a P1, nothing is. Teams miss the SLA on the findings that matter because they are busy with the ones that do not.

It burns trust

Each critical that turns out unreachable teaches engineering to discount the next one. Call it the trust tax. It compounds.

It cannot prove the fix

A patch ticket closes when the version changes. Nobody reruns the attack, so partial fixes and regressions quietly survive.

It fails the audit question

Boards, regulators and insurers now ask how you know a risk was real and how you know it is closed. A spreadsheet of CVSS scores answers neither.

The proof-first remediation workflow

The rule is short: unproven findings never reach engineering, and a ticket cannot close until the original trigger fails on retest.

FROM SCANNER FINDING TO VERIFIED CLOSURE

01 · SECURITY

Validate the finding through the five gates

02 · SECURITY

Assign a verdict and its SLA tier

03 · SECURITY

Attach the proof package to the ticket

04 · ENGINEERING

Fix or mitigate within the tier SLA

05 · SECURITY

Rerun the original trigger

06 · CLOSE

Trigger fails. Retest record attached, ticket done

Not exploitable at step 02? No ticket. A suppression record with evidence and a revalidation trigger instead. Trigger still fires at step 05? Back to engineering.

What goes in the proof package

A ticket built on proof carries six pieces of evidence. If any piece is missing, the ticket goes back to security, not forward to engineering.

The verdict

Exploitable with reach, exploitable but contained, not exploitable or undetermined. The method behind each verdict is in How to Validate Whether a Vulnerability Is Actually Exploitable.

The entry point

Where the attacker starts: the internet, a partner network or a compromised workstation.

The safe trigger record

The non-destructive payload that ran, when it ran and what it returned.

The controls in the path

Which controls the trigger passed and which, if any, stopped it.

The reach

What a successful attacker could touch next: identities, data stores, services and any crown jewel on the path.

The retest instruction

The exact test that will run again after the fix, so closure is proven rather than declared.

The bar: an engineer can read the package in two minutes and reproduce it in ten.

Tie SLAs to verdicts, not scores

Here is the swap: replace severity tiers with verdict tiers. The SLA follows what was proven, not what a score implies.

TIER 1

Reach to a crown jewel

Emergency change. Fix or mitigate within days, then retest.

TIER 2

Reach to non-critical assets

Standard sprint SLA, retest on merge.

TIER 3

Exploitable but contained

Normal backlog, plus automatic revalidation whenever the containing control changes.

TIER 4

Not exploitable here

No ticket. A suppression record with its evidence and a revalidation trigger.

One tip: set the day counts with engineering, not for them. The tiers hold because each one is backed by evidence both teams can see.

Retest to close

A ticket closes only when the same trigger fails. Version checks are not enough. A configuration rollback, a second vulnerable instance or a partial patch can leave the exposure wide open while the scanner happily reports green.

So rerun the original test, attach the failed result to the ticket, and only then mark it done. That retest record doubles as your audit evidence: the risk was real, and now it is gone.

Worked example: from verdict to ticket

Let's take the Log4Shell finding from the exploitability note and change one fact. This time the billing service sits behind the public API gateway and egress is open. Here is the proof package that travels with the ticket.

CVE-2021-44228 NVD ↗ Attached to ticket SEC-4182

proof-package.yaml

# proof-package.yaml (attached to ticket SEC-4182)
finding: CVE-2021-44228
asset: billing-service (prod, eu-west-1)
verdict: exploitable_with_reach
entry_point: internet via api-gateway
trigger:
  type: dns_canary
  ran_at: 2026-11-02T09:14:07Z
  result: callback received after 1.2s
controls_in_path:
  waf: passed, no matching rule
  egress_firewall: passed, tcp/1389 open
reach:
  identity: svc-billing (IAM role)
  data_store: s3://billing-invoices (customer PII, crown jewel)
retest:
  method: rerun dns_canary with a fresh token
  pass_condition: no callback within 60s

An engineer can read that in two minutes. Every line is something that happened, not something a score implies.

SLA tiers as code

Now encode the tier rules so routing is automatic and auditable. The day counts below are examples only. Agree the real ones with engineering.

sla-policy.yaml

# sla-policy.yaml
tiers:
  - tier: 1
    when: verdict == "exploitable_with_reach" and reach.crown_jewel
    fix_within_days: 3
    change_type: emergency
  - tier: 2
    when: verdict == "exploitable_with_reach"
    fix_within_days: 14
  - tier: 3
    when: verdict == "exploitable_contained"
    fix_within_days: 45
    revalidate_on: [containing_control_change]
  - tier: 4
    when: verdict == "not_exploitable"
    create_ticket: false
    revalidate_on: [deploy, config_change, new_exploit_technique]
close_rule: retest.pass_condition == true

What changes for the engineer

The ticket no longer argues about whether the risk is real. It shows the callback, the open egress port and the PII bucket the role can read. The fix is obvious too: remove the lookup class or upgrade, and tighten egress. And the ticket closes itself only when the retest gets no callback.

How to measure the outcome

How will you know it is working? Watch these five numbers.

Urgent queue size

Tier 1 and Tier 2 tickets open at any time. It should fall sharply once Tier 4 findings stop becoming tickets.

Tier 1 time to fix

Median days from verdict to verified closure for proven paths to crown jewels.

Ticket rejection rate

The share of security tickets engineering pushes back. Proof should drive it toward zero.

Retest failure rate

The share of claimed fixes where the trigger still succeeds. It exposes partial fixes early.

Evidence coverage

The share of closed criticals with a stored retest record. Auditors will ask for this number.

How Hayrok approaches proof before remediation

Hayrok builds the proof package for you, as part of governed adversarial exposure validation.

Genesis

Runs governed validation against findings from the scanners you already use.

Evidence Fabric

Stores every trigger, control result and path under an Evidence Contract, so each ticket links to the same proof security saw.

AGIE

The Attack Graph Intelligence Engine adds the reach, including whether the finding sits on a path to a crown jewel.

Risk Engine

Assigns the verdict tier. When engineering ships the fix, Hayrok reruns the original trigger and attaches the result.

Hay Assist

Lets engineers ask plain questions about any ticket, like why it is Tier 1 or what changed since the last test.

FAQ

What does it mean to prove a vulnerability is exploitable?

It means running a safe, governed test that shows the vulnerable code can be reached and triggered in your environment, and recording what controls did and what an attacker could reach.

Will proof-first remediation slow down urgent fixes?

No. It speeds them up. Engineering stops spending time on unreachable findings, and proven Tier 1 tickets skip the debate about whether they are real.

What should happen to findings that are not exploitable?

Record them with their evidence and a revalidation trigger. They leave the queue but stay visible, and they return automatically if the environment changes.

How does proof before remediation fit into CTEM?

It is the validation stage of CTEM. Validation filters discovered issues, confirms them against real defenses and retests after mobilization.

Do auditors accept validation evidence?

Auditors look for evidence that risk was assessed and that fixes worked. A stored trigger, verdict and retest record answers both questions directly.

Put proof on your next critical ticket

Pick one critical from this week's queue. We will build its proof package with you and show the tier it lands in.

Book a validation walkthrough → See sample packages in the Proof Library

At Hayrok Labs we question everything and Validate what matters.