Findings are cheap. Fixes are the product.

Every pentest ends with a report. Most reports end in a ticket queue. Six months later the same vulnerability class shows up in a different service, because the finding was fixed — if it was fixed at all — and the pattern that produced it was never addressed.

That's the gap between a report and security. Findings are cheap. Fixes are the product.

What hardening actually means

Hardening is the engineering work that turns a finding into a durable improvement. It comes in layers:

The direct fix. Patch the code, fix the config, close the hole. This is the minimum, and it's where most engagements stop. It's also the least valuable part on its own, because it fixes one instance of the problem.

The guardrail. The rule that prevents the next instance. Input validation middleware that rejects the whole injection class. An authorization check enforced at the framework level instead of per-endpoint. A pre-commit hook that blocks secrets before they reach the repo. Guardrails turn one finding into protection for the entire codebase.

The detector. The thing that catches it if it comes back. A custom Semgrep rule for your codebase's specific anti-patterns. A SIEM detection for the exploitation signature. A scheduled scan that re-checks the fixed endpoints. Detections turn a point-in-time fix into ongoing assurance.

The automation. The pipeline that makes the safe path the easy path. Dependency updates that open their own pull requests. IaC policies that reject insecure defaults at plan time. Eval harnesses that regression-test security properties on every deploy.

Each layer compounds. The direct fix protects one endpoint. The guardrail protects the codebase. The detector protects the future. The automation makes the secure default automatic.

Why this is a separate stage

Most security shops stop at the report. Their job was to find things; fixing them is your problem. That's a reasonable division of labor — and it's also why findings recur. The team that found the bug understands it best, and the context is freshest the week after the test, not six months later.

We run hardening as its own engagement stage: fixed-scope sprints that take a findings list — ours or someone else's — and convert it into merged code, deployed guardrails, and running detections. You can bring us a report from another firm. We'll still harden it.

The retest closes the loop

Every hardening sprint ends with verification: the original findings re-tested, the guardrails attacked, the detectors fired against live test cases. A fix that isn't verified is a hypothesis.

If you have a findings list gathering dust — or a pentest coming up and no plan for what happens after — book a scoping call. Thirty minutes, and we'll tell you what hardening that report would actually take.