Pentest Findings Engineering Remediation Guide: How to Get Developers to Fix Security Issues

The moment you receive the pentest report, do not wait for a formal debrief to start creating tickets. Create a ticket for every finding above Low severity before the debrief meeting.

Why before the meeting: The kickoff call often generates pressure to deprioritize. If tickets already exist, they have gravity. If tickets don't exist, the conversation is easier to defer.

Ticket creation template:

Title: [PENTEST] [SEVERITY] [SHORT FINDING NAME]
Example: [PENTEST] CRITICAL: SQL injection in /api/user/search endpoint

Labels: security, pentest-2026-Q2, severity-critical
Assignee: [Engineering lead to triage and reassign]
Due date: [per SLA -- Critical = 7 days from report date]

Body:
## Finding
[Copy the finding summary from the pentest report verbatim]

## What an attacker can do
[Plain English description of impact -- write this yourself,
not from the report. Make it concrete.]
Example: "An unauthenticated attacker can send a crafted request
to our user search endpoint and read any data from our users
table, including hashed passwords and PII for all 14,000 customers."

## Reproduction steps
[Copy from report or ask pentester to provide]

## Recommended fix
[Copy from report; add implementation detail specific to your stack if you can]

## Verification
[How to confirm the fix is effective -- ideally: run the original
poc command and confirm it fails]

## References
[CVE or CWE number if applicable; link to OWASP guidance]

For each ticket, immediately answer:

1. Which team owns this code/system? (that's the assignee)
2. Is this internet-exposed? (affects SLA)
3. Does our environment reduce severity? (document if so)

Pentest firms use CVSS or their own severity scale based on generic worst-case scenarios. Your environment has compensating controls, architecture differences, and data context the pentester doesn't fully know. Reclassify before ticketing.

Reclassification decision tree:

Start with the pentest firm's severity.

Adjust DOWN one level if:
  • The vulnerable system has no internet path (fully internal)
  • The vulnerability requires authenticated access with a role
    that is limited to 2-3 employees with strong vetting
  • A compensating WAF/IDS rule is verified to block the attack
  • The data accessible via the vulnerability is not classified
    as sensitive by your data classification policy

Adjust UP one level if:
  • The vulnerability is on a system you classified as higher
    criticality than the pentester assumed
  • The pentester rated it Medium but it chains to a Critical
    finding (e.g., SSRF that leads to credential exfiltration)
  • The system has had a prior incident via a similar technique

Never adjust below the pentester's rating by more than one level
without CISO or security lead sign-off.

Document reclassification in every ticket:

## Severity reclassification
Original severity: Critical (CVSS 9.3)
Reclassified to: High
Reason: The affected endpoint requires authentication with the
'admin' role. Our admin role is limited to 3 operations engineers
who have completed background checks. Attack chain still requires
valid admin credential -- not a zero-click exploit.
Approved by: [NAME, TITLE, DATE]
Review date: [90 days -- if compensating control changes, re-evaluate]

Objection 1: 'That's not exploitable in our environment'

This is sometimes correct and sometimes motivated reasoning. Handle it as a process, not a debate:

1. Ask the engineer to document their reasoning in the ticket:
   'What specific compensating control makes this unexploitable
   in our environment?'

2. Evaluate the control against three questions:
   a. Is the control verified to be in place? (not assumed)
   b. Would the control remain effective if the environment changed?
   c. Is this 'zero risk' or 'difficult but not impossible'?

3. Outcome:
   - If the control is verified and durable: reclassify to
     'Accepted risk with compensating control,' document,
     set a 90-day review date
   - If the control is assumed or fragile: maintain severity
     and require remediation

Objection 2: 'This is too expensive to fix'

Translate to business terms:

Cost to fix: $X (engineering hours)
Cost of a breach via this vector: $Y (use Ponemon
benchmarks or your insurer's breach cost estimate)
Risk-adjusted annual cost of not fixing:
  $Y x probability of exploit in 12 months

If cost to fix < risk-adjusted cost of breach: fix it
If cost to fix > risk-adjusted cost of breach:
  document formal risk acceptance with executive sign-off

Objection 3: 'We'll fix it in the next sprint'

Require specificity before accepting:

Unacceptable: 'We'll fix it next sprint'
Acceptable: 'This is in Sprint 47 (starts May 27),
assigned to [ENGINEER], estimated 4 story points'

If it slips from Sprint 47: 'This has now slipped twice.
I'm escalating to [ENGINEERING MANAGER] to discuss
reprioritization. The risk of keeping this open is [SPECIFIC].'

One spreadsheet, updated weekly. Every open finding is a row. Share it with engineering leadership -- not just security.

Finding ID | Title | Original Sev | Reclassified Sev | Assignee | SLA Date | Status | Sprint | Blocked By
PT-001 | SQLi in /api/user/search | Critical | Critical | @alice | 2026-06-01 | In Progress | Sprint 47 | -
PT-002 | IDOR on /api/orders | High | High | @bob | 2026-06-15 | Open | Not scheduled | -
PT-003 | Missing HSTS header | Medium | Low | @carol | 2026-08-01 | Open | Backlog | -
PT-004 | Reflected XSS on search | High | High | @dave | 2026-06-15 | Accepted Risk | N/A | Compensating: WAF rule PT-WAF-001
PT-005 | Outdated jQuery 1.x | Medium | Medium | @alice | 2026-08-01 | Closed | Sprint 46 | -

Weekly 15-minute register review with engineering lead:

Agenda:
1. Any findings closed this week? (celebrate + close ticket)
2. Any findings at risk of missing SLA? (what's the blocker?)
3. Any new accepted-risk decisions needed? (brief discussion + document)
4. What's the overall closure rate? (% closed of total)

Closure rate formula:

Closure rate = (Findings closed or accepted) / Total findings x 100

Target at 30 days: >40% of Critical/High findings closed
Target at 60 days: >70% of Critical/High findings closed
Target at 90 days: >90% of Critical/High findings closed or formally accepted

Every remediated finding should be retested before closing the ticket. Developers fix what they understood; the fix may not address the actual vulnerability.

Lightweight retest process (for internal teams without a retainer):

For web application findings:

# If the pentest firm provided a curl PoC, re-run it after the fix
# Example: original SQLi test
curl -s 'https://app.example.com/api/user/search?q=test%27%20OR%20%271%27%3D%271' \
  -H 'Authorization: Bearer YOUR_TOKEN'

# After fix: confirm the input is sanitized
# Expected: no SQL results returned, or a 400/422 error
# Unacceptable: same data returned, or a generic error that suggests
# the query still ran

For infrastructure findings:

# Missing encryption at rest -- verify after fix
aws s3api get-bucket-encryption --bucket BUCKET_NAME
# Should return a ServerSideEncryptionConfiguration

# Open security group -- verify after fix
aws ec2 describe-security-groups --group-ids sg-XXXXXXXX \
  --query 'SecurityGroups[].IpPermissions'
# Should not include 0.0.0.0/0 on port 22

For Critical findings: always request a spot retest from the original pentest firm (most include one in the engagement scope). A self-verified Critical closure is a risk.

Closing a ticket:

Status: Closed - Verified
Closed by: [NAME]
Verification method: [PoC re-run / pentest firm retest / automated scan]
Verification date: [DATE]
Verification evidence: [screenshot / log / command output attached]

Remediation velocity depends entirely on the relationship between security and engineering. These behaviors build the relationship; their opposites destroy it.

Do:

• Join engineering sprint planning as an observer before adding security tickets to the backlog
• Ask engineers 'what would make this easier to fix?' rather than 'why haven't you fixed this?'
• Provide the fix, not just the finding -- include code snippets where you can
• Acknowledge when an engineer's compensating control argument is correct
• Share external examples of the same vulnerability being exploited (creates urgency without blame)
• Publicly recognize engineering leads when they close findings ahead of SLA

Don't:

• Escalate to the CTO before talking to the engineering lead first
• Assign severity labels that engineers perceive as disproportionate (undermines credibility for the next report)
• Let findings sit unticketted for more than 48 hours after report delivery
• Frame remediation as 'security team work' -- it is engineering work, security is the coach
• Create a separate security backlog that engineers don't own -- findings must live in the same backlog as everything else