Pen Test Remediation for a Legacy Product

Pen test remediation, from report to retest. Three muted findings marked Critical, High and Medium join at one root cause tile, and a lime arrow leads to a blue Retest tile with a tick.

Quick answer: Pen test remediation is the set of code, configuration and infrastructure changes that close each finding in a penetration test report. CIS Controls safeguard 18.3 is dedicated to it. Vulnerability remediation that holds at the retest follows an order. Rank each finding by risk in your product, trace it to its root cause, fix that class of weakness across the codebase, prove each fix in staging and record it for the retest.

Your penetration test report lists findings in a legacy product your organisation depends on, and an auditor, a customer or your security team needs them closed. The code has been in service longer than most of its team and has few tests, and the people who built it have moved on to other roles. Penetration test remediation on that code has to close the findings and keep them closed, without breaking the screens and integrations people rely on.

The quick route is to patch each finding at the line the tester reported and book the retest. That can close the report. It also leaves the pattern behind each finding in place, and the next test can find the same weakness somewhere else in the code.

This guide is for the engineering team that closes the findings, from reading the report to a closed retest, without a rewrite.

What a penetration testing report asks of the team that fixes it

Each finding in a penetration testing report usually carries a description of the weakness, a severity rating, the tester’s evidence, the affected location (a URL, endpoint, parameter or host) and a recommended fix. How the tester reached each finding depends on the methodology they follow. NIST SP 800-115, NIST’s technical guide to information security testing and assessment, is one. Others include the OWASP Web Security Testing Guide for web applications, the Penetration Testing Execution Standard (PTES) and ISECOM’s Open Source Security Testing Methodology Manual (OSSTMM). In Australia, CREST accredits testing companies and certifies individual testers.

Whichever methodology the tester follows, the report leaves two questions for the team that fixes it. Where else does the same weakness live in the code? And what will the fix break? A test runs to an agreed scope and time window, so each finding records the instances the tester proved in that time. The fixing team works from the code, and that is where both answers sit.

Rank pen test findings by the risk they carry in your product

The ranking has to stand up against what your organisation answers to, whether that is ISO 27001, SOC 2, the ISM and Essential Eight, or a customer’s security review. Engineering proposes the order, and your security or compliance owner decides it.

Start from the severity rating in the report, then go further. Where that rating is a CVSS score, FIRST, which maintains CVSS, draws the line in its CVSS v4.0 User Guide. A Base score rates how severe the vulnerability is on its own terms, and judging risk takes what you know about the environment it runs in and the threats against it.

Risk in your product turns on how exposed the affected component is, what data sits behind it and whether an attacker has a working path to it. Take two findings. A medium-severity flaw on an internet-facing production service that holds customer records can outrank a high-severity flaw on an internal test server with no live data. The CIS guidance on safeguard 18.3 warns against ranking on the score alone for the same reason.

Sort the ranked list into three groups.

Fix now. Exposed, exploitable findings on live data, fixed and released ahead of the sprint plan.
Fix in sprint. The rest of the confirmed findings, scheduled into the remediation sprints in ranked order.
Mitigate and record. Findings whose fix needs a larger change, held down by a compensating control and logged in the risk register until the change ships.

Mitigation and remediation sit side by side in that list, and they are different things. A mitigation is a compensating control that lowers the risk, such as a network firewall rule, a web application firewall rule or a feature switched off. Remediation removes the root cause in the code or configuration. Treat a mitigated finding as open until it is remediated, and say so in the risk register.

The order is set. The next question is how far each fix reaches.

Vulnerability remediation that fixes the whole class of weakness

A finding shows where the tester proved a weakness. In legacy code, those places are rarely the only ones. These are the findings we see recur, and what each one usually points to.

One SQL injection finding usually means every query in that part of the code is built by joining strings with user input.
One missing authorisation check usually means routes are protected one at a time, by hand, and some were missed.
One cross-site scripting finding usually means output is escaped template by template, and some templates skip it.
One vulnerable library usually means nothing in the build checks dependencies against known vulnerabilities.

Our vulnerability remediation traces each finding to its root cause, so the whole class of weakness is fixed wherever it appears in the codebase. We search the code for every place the pattern appears and fix the pattern in one shared place. That might be a parameterised query helper in place of string-built SQL, an authorisation middleware that applies to every route by default, or a framework setting that turns on output escaping in every template.

Each fix gets a test that proves the weakness is gone. Then an automated check in the pipeline, such as a static analysis rule, flags the pattern if a later change brings it back.

Say the report lists one injection finding on a search endpoint. Fixed at that line, the finding closes. Traced back, it leads to a helper that builds every query by joining strings, used by the reporting screens, the admin search and the export jobs. Moving that helper to parameterised queries closes the reported finding and every unreported instance that runs through it, and the static analysis rule flags new string-built queries before a change merges.

Fixing the class is the core of the remediation sprints our senior developers run alongside your team through our secure software development service.

What legacy code changes in a pen test remediation plan

A legacy product can close its findings without a rewrite when the fixes fit within its shared code, configuration and dependencies. Four features of legacy code change how the plan is built.

Few tests. Before changing the code around a finding, write tests that pin down what it does today. The fix then removes the weakness without breaking the features your users rely on.
End-of-life frameworks and dependencies. Some findings close only with an upgrade to a supported version. Size those separately, because an upgrade can touch far more of the code than a single fix.
Undocumented behaviour. Legacy code holds business rules nobody wrote down. When a fix changes what a screen or an integration does, check with the people who use it before release.
Fixes that need a platform change. When the fix needs a new runtime or framework, mitigate now, record the finding in the risk register and plan the upgrade as its own release. Where the platform itself is the fix, our guide to application modernisation covers how to move it in stages.

On a codebase another team built, we score the code against the nine ISO/IEC 25010 product quality characteristics before the first sprint, with evidence such as a file and line or a tool report behind every mark. The score shows where the remediation plan should spend effort first.

With the order set and the legacy constraints known, the plan fits into seven steps.

Seven steps of pen test remediation, from report to closed retest

We work from any tester’s report, including for legacy products another team built, and we coordinate the retest with the tester you choose so the report can be closed. To start, the fixing team needs the report, access to the repository and the environments, time from a product owner who knows how the product is used, and the tester’s contact for the retest. How long remediation takes depends on the number of findings and how many share a root cause, how much of the code has tests, which dependency upgrades are needed, and when the tester can book the retest. A vulnerability remediation plan sets those four out before the first sprint, so the retest date is one the team can hold.

Reproduce each finding and give it an owner. Confirm it in a test environment from the tester’s evidence, and name the developer responsible for it.
Rank by risk in your product. Weigh exposure, data and exploit path alongside the severity score, and agree the order with your security owner.
Trace each finding to its root cause. Find the pattern behind it and every place that pattern appears in the code.
Fix the class and add a test. Change the shared code, setting or middleware, and add a test that fails before the fix and passes after it.
Check each fix in staging before release. Run the tester’s original steps against the fixed build, then the tests that pin down existing behaviour.
Write a fix record per finding. Set out what was vulnerable, what changed and the evidence, so the tester can check each finding against its record.
Book the retest and record anything accepted. Agree a retest with your tester, and log any finding your organisation accepts or mitigates in the risk register, with an owner and a review point.

Keep pen test findings from returning after the retest

Closing the report is the first milestone. Weaknesses return through new code and ageing dependencies, so the lasting fix sits in the delivery pipeline and the maintenance cadence.

Pipeline checks. Static analysis (SAST) in CI, dependency and secret scanning, a software bill of materials (SBOM) with each build, and signed releases. Once the retest is closed, our DevOps consulting team can add these to the pipeline that ships the product.
A patch cadence. Dependencies and the runtime are updated on an agreed schedule, so the remediation of vulnerabilities in third-party packages is routine and end-of-life versions stop building up. Our software support and maintenance service keeps the product patched on that cadence under a support agreement.
A codebase review before the next test. Scoring the code again ahead of the next pen test shows which weakness classes remain and where to look first.

We have designed, built and supported software since 2008 with an in-house Australian team. Our senior developers work through pen test findings in sprints alongside your team, and we coordinate the retest with the tester you choose. If you have a report in hand, send it to us and we will tell you which findings share a root cause and what the fix for each class covers. The remediation sprints are described on our secure software development page.

Fix the pattern behind each finding, and the retest is a formality.

Frequently asked questions

What is pen test remediation?

Pen test remediation closes the findings in a penetration test report with changes to the code, configuration or infrastructure. Each finding is ranked by risk in the product, traced to its root cause and fixed across the codebase. Each fix is tested, checked in staging and recorded, so the tester can confirm it at the retest. CIS Controls lists it as safeguard 18.3.

How long does pen test remediation take?

Four things decide it. The first is the number of findings and how many share a root cause, because findings that share a pattern close together. The others are how much of the code has tests, whether any fix needs a dependency or framework upgrade, and when your tester can book the retest. Framework upgrades are sized separately from the other fixes, so they can be planned as their own release.

What is the difference between remediation and mitigation?

Remediation removes the cause of a finding, for example by changing the code so user input can no longer run as part of a database query. Mitigation lowers the risk while the cause stays, through a compensating control such as a firewall rule or a disabled feature. Treat a mitigated finding as open, and record it in the risk register with an owner and a plan to remediate it.

Do we need a retest after fixing pen test findings?

Yes, when an auditor, a customer or your own policy needs the findings closed. A retest is where your tester confirms each fix, and it lets the report be closed. Give the tester a fix record for each finding, setting out what was vulnerable, what changed and the evidence that it holds. Where fixes are checked in-house instead, the CIS guidance on safeguard 18.3 has the people who fix findings report back so an internal team can validate them.

Should we fix medium and low findings?

Rank them by risk in your product before deciding. A medium finding on an internet-facing system that holds customer data can matter more than a high finding on an internal test server. Low findings can share a root cause with higher ones, so fixing the class closes them too. Anything you leave open goes in the risk register with an owner and a reason.

Can a legacy product pass a pen test without a rewrite?

It can, when the fixes fit within its shared code, configuration and dependencies. Many findings trace to one pattern, such as how queries are built or how routes are protected, that can be fixed in one place. Tests written around current behaviour protect the features users rely on. When a fix needs an unsupported platform replaced, mitigate first, record the finding and plan the upgrade or a staged modernisation.

What does the team fixing the findings need from a penetration testing report?

For each finding the team needs the reproduction steps, the affected location (a URL, endpoint, parameter or host), the tester’s evidence, the severity rating and the recommendation. With those it can confirm the finding in a test environment, trace its root cause and write a fix record the tester can check at the retest. Where a field is missing, ask the tester before the first sprint starts.