Security insights

Why a Vulnerability Report Is Only Half the Job

The report ends. The actual security work — the part that protects users — is what happens after.

BU
BugSwagger Team

Penetration tests produce reports. Reports have findings. Findings have recommendations. The expectation is that the recommendations get followed and the bugs go away.

In practice, that's where most security programs quietly fail.

What we see in remediation

We've revisited dozens of organizations 6–12 months after their initial test. The pattern is consistent: critical findings get fixed in days. High findings get fixed in weeks. Medium and low findings live in JIRA forever.

The problem isn't that nobody cares. It's that the report lands on a desk, the team picks up the items that look scariest, and the rest get triaged into the regular product backlog, where they compete with feature work and lose.

The components of good remediation

The teams that actually close their gaps have a few things in common:

1. A single owner per finding

Every finding has a name attached to it. Not a team — a person. The accountability shifts from "we should" to "I will, by next sprint."

2. Deadlines tied to severity

Critical: 7 days. High: 30 days. Medium: 90 days. Low: next quarter. Without explicit deadlines, severity becomes feelings, and feelings get overridden by whatever's on fire today.

3. A retest, scheduled before the project even starts

The most powerful forcing function for getting fixes done is knowing someone will check, on a specific date. We bake the retest into the engagement contract for this reason. The team works toward a known checkpoint.

4. Root cause analysis on the systemic findings

If we found five instances of broken authorization, the fix isn't five separate patches. It's a refactor of how the team does authorization, and a new code review checklist item. The report flags symptoms; the team has to find the disease.

The follow-up engagement

We've shifted our default engagement model over the last year. Instead of "test, report, leave," we offer "test, report, retest" as standard. The retest happens 30–60 days after the initial report, on the same scope.

Roughly half of the value of an assessment shows up in that retest. Issues that looked simple turn out to have surprising depth. Issues that looked complex turn out to have already been fixed in a different way. The conversation about what to do about it is, in many ways, more useful than the discovery itself.

What "done" looks like

A clean retest report is the artifact most clients end up using during sales conversations. Procurement teams, compliance officers, and security questionnaires increasingly ask for it. "We had a pentest" is becoming a baseline. "We had a pentest and here's the verified remediation report" is becoming the standard.

If your current security partner stops at the report, you're missing the part that actually changes your posture.

Found this helpful?

Want a hand-tested assessment for your own stack?

Tell us what you're protecting — we'll respond within one business day with a scoped proposal written by a pentester.