Why Pentest Findings Take Months to Fix

Most pentest findings stay exploitable for months after they are confirmed. The delay is rarely the fix itself. It is everything that happens between the report and the fix.

Follows on from Time's not on your side: why security testing runs slower than the software it tests.

Ask a security lead when their last penetration test happened and you will usually get a date. Ask when the last critical finding from that test was fixed, verified and closed, and the answer takes longer.

In a previous piece I described three clocks running at different speeds: the release clock, the attacker clock and the testing clock. Most of the industry now accepts that the testing clock is too slow. This piece is about a fourth clock that gets far less attention, because it only starts once the test is over.

A finding is not a fix. Between the moment a tester confirms a vulnerability and the moment it stops being exploitable in production, another clock is running. In most organisations it is the slowest of the four.

What happens after a penetration test report is delivered

Walk through what usually happens after a tester confirms something serious.

The test window closes. Unless a finding is critical enough to escalate on the spot, it is held for the report. Writing that report takes time after testing ends.
The report arrives as a document. It is addressed to the security team, not to the engineers who own the affected code.
Security triages it. Someone maps each finding to a system and an owner, rescores it against an internal risk model, and decides what gets raised.
Tickets are written. A paragraph of tester prose becomes a ticket an engineer can act on. Context is lost in the translation every time.
The ticket waits. It joins a backlog next to feature work that has a deadline attached. Medium severity findings can sit there for quarters.
A fix ships. The engineer fixes what the ticket describes, which is not always the whole of what the tester found.
Someone retests, eventually. Confirming the fix often means bringing the tester back, booked as a separate piece of work or deferred to next year's test.

None of these steps is unreasonable on its own. Taken together, they mean a vulnerability confirmed in the first week of an engagement can still be exploitable months later, while everyone involved has done their job properly.

Why pentest findings don't get fixed

Four things slow the fourth clock down, and they compound.

The evidence does not survive the handoff. The tester knew exactly what they did: the request, the response, the account they used, the state the application was in. The report compresses that into a description and a severity. The engineer who receives the ticket has to rebuild the exploit before they can understand it. "If they cannot reproduce it, the ticket stalls. Someone goes back to the pentest provider for clarification, a call gets scheduled, and the vulnerability stays open while everyone waits."

Ownership does not map cleanly. A report is organised by vulnerability. An engineering organisation is organised by team. One authorisation flaw can run through an API owned by one team and a client owned by another. A finding that belongs to everyone tends to be fixed by no one in particular.

Severity gets negotiated. The tester assigns a score without full business context. Security rescores it. Engineering pushes back, because a score on its own is an argument rather than a fact. Each round is reasonable, and each one costs a week. As I argued in What AI penetration testing actually is, a severity without a proof of exploitation is a guess, and guesses invite debate.

Verification is expensive, so it gets skipped. Verification often becomes its own project. Many providers treat the retest as a separate engagement, with a new quote, a new purchase order and a new slot in the calendar, so it gets deferred or skipped altogether. Teams confirm the fix themselves by checking that the code changed. Code changing is not the same as the vulnerability being gone. Partial fixes are common. The endpoint the tester used gets patched. The neighbouring endpoint with the same flaw does not, because nobody tested it again.

How to reduce vulnerability remediation time

The fourth clock does not speed up because engineers are asked to work faster. It speeds up when the finding arrives in the form the engineer needs, in the place they already work. Three properties matter.

It arrives close to the change. A finding raised against this week's release is fixed by the person who wrote the code, while they still remember why they wrote it that way. A finding about code shipped six months ago is archaeology.

It arrives with proof. The exploit, reproduced and attached. Nothing to reconstruct, and very little to argue about, because the severity rests on what actually happened rather than on a score.

It arrives as a proposed fix, where the code lives. A pull request against the affected code goes through the same review as any other change. Engineers judge it on its merits. They merge it, amend it or reject it. For many findings, the translation step from report to ticket largely disappears.

One further thing follows. If the same test can run again against the fixed build, verification can stop being a rebooking and become a rerun. It can also run everywhere the flaw could exist, so the neighbouring endpoint gets checked too.

For a security leader, this changes which number is worth tracking. The question is not how many findings the last test produced. It is how long each one was exploitable, measured from the moment it was confirmed rather than the moment the report landed.

What automated remediation can't fix

Three honest limits on all of this.

A pull request is a proposal, not a fix. Some vulnerabilities are architectural: an authorisation model that is wrong at the root, or a trust boundary in the wrong place. No generated pull request fixes those. They need a design conversation and an engineer who understands the system, and I am not claiming otherwise.

Faster findings do not solve prioritisation. A team receiving proven findings every release still has to decide what to fix first. Removing friction can increase volume, and deciding which findings matter most remains a human judgement.

The formal report still has a job. Auditors, regulators and boards want a point in time record with a named firm behind it. Continuous findings do not replace that document. They change what it says when it is written: fewer surprises, and a much shorter list of open items.

That last point matters to me. The scheduled engagement is not going away, and I do not think it should. What should go away is the assumption that the report is where the work ends.

Where Deus Rex sits

We built Deus Rex around the handoff problem as much as the testing problem. Findings are confirmed by exploitation, arrive with the evidence attached, and come with a fix raised as a pull request against the affected code, which your team reviews and merges on its own terms. Because access to the application is established once, retesting a fix is a rerun rather than a new engagement.

The instinct behind it came from experience. Cyrex spent twelve years writing penetration test reports for studios and enterprises where a live failure was a serious event, and saw what happened to those reports after they were delivered. It is why Cyrex quoted regression testing as part of the original engagement, so verifying a fix never started a new commercial cycle. Deus Rex is what we built once we stopped accepting that the report was the end of the engagement.

If you would like to know how long your last critical finding was really open, that is a good place to start a conversation.

deusrex.ai