The thesis: the gap between a red team finding and an engineering fix is organizational, not technical. The security team cannot close it alone, and the red team cannot close it by writing better reports. It closes only when remediation is structured as engineering work, with the same ticketing, ownership, and accountability that ship features.
A red team engagement ends. The report lands: dozens of findings, a handful critical, a handful high. Executives nod gravely. The report goes into a shared drive. Six months later, a penetration test finds the same critical issues. Nobody is surprised. Nobody is held accountable. Nobody changes the system that produced the cycle.
This is not a failure of the red team. It is a failure of the organizational machinery that is supposed to convert findings into fixes, the handoff from security to engineering, the prioritization against feature work, the verification that the fix actually works. Most security programs silently break down at one of those three joints.
Why findings sit unactioned
The report is written for the wrong audience
Red team reports are written by security people for security people. They describe vulnerabilities in security terms: CVSS scores, attack chains, MITRE ATT&CK mappings. An engineering team reading this report needs different information: which code is affected, what the fix looks like, how to test it, and how long it will take.
A finding that says “SQL injection in the user search endpoint (CVSS 9.8)” tells an engineer almost nothing. A finding that says “the /api/users/search endpoint in UserController.java:142 concatenates the q parameter into a SQL query, replace with a parameterized query using PreparedStatement” is actionable.
The gap between these two descriptions is where findings go to die. If the red team does not provide engineering-ready detail, someone else has to translate, and that someone else is often nobody.
Severity ratings do not map to engineering priority
A CVSS 9.8 finding that requires local network access to a development environment does not have the same business risk as a CVSS 7.5 finding on the production login page. But the report ranks them by CVSS, and engineering teams push back because the “critical” findings are in systems they consider low-risk. Engineering prioritizes by impact to users; security prioritizes by exploitability and theoretical worst case. Neither lens is wrong, but nobody translates between them, and this is the same dichotomy the compliance-driven vs threat-driven framing names at the program level.
Nobody owns the fix
A red team finding is not a feature request. It does not have a product owner, a sprint, or acceptance criteria. It is an artifact that exists in a security report, disconnected from the engineering workflow. Until the finding becomes a ticket in the engineering backlog, with a clear scope, an owner, and a deadline, it does not exist in the engineering team’s reality.
Insight
If it is not a ticket, it is not real
Engineering teams manage work through tickets. A red team finding that lives only in a PDF report is invisible to the engineering planning process. The single highest-leverage change most security programs can make is ensuring that every remediation action becomes a tracked, owned, prioritized ticket in the engineering team’s system.
The incentive misalignment
Red teams are rewarded for finding vulnerabilities. The more findings, the more successful the engagement. Engineering teams are rewarded for shipping features. Fixing a vulnerability that no customer asked for competes directly with feature work that drives revenue.
Security teams are caught in the middle: they need engineering to fix things, but they have no authority over engineering’s roadmap. The result is a negotiation where security presents risk and engineering presents opportunity cost. Without executive air cover, security usually loses.
Treating remediation as real engineering work, with allocated time, measured progress, and consequences for missing SLAs, requires organizational commitment, not a better report. The “just one more exception” trap compounds here: every unfixed finding is an exception that accumulates risk silently.
What works
Deliver findings inside the engineering workflow
The most effective red team reports I have seen are not reports at all. They are branches. The red team finds the vulnerability, writes a fix (or a skeleton of a fix), and submits it as a pull request. The engineering team reviews and merges; their normal workflow.
This is not always possible. Complex architectural issues cannot be fixed in a PR. But for the common classes, injection flaws, misconfigurations, missing authentication checks, insecure defaults, a PR is faster and more effective than a paragraph in a report.
Embed security engineers in product teams
A security engineer who sits with the product team understands the codebase, the deployment pipeline, and the constraints. When a red team finding arrives, the embedded engineer can immediately translate it into the team’s context, estimate the fix effort, and help prioritize it against other work.
The hiring pool for this role is thin, you need engineers who can ship product code and who think adversarially, and the model only works if the embed reports to security, not to the product team they sit with. Done right, it eliminates the translation gap that kills most remediation efforts. Done wrong, you get a security engineer who quietly becomes another product developer.
Track remediation with SLAs
Define maximum remediation times by severity: critical within 7 days, high within 30 days, medium within 90 days. Track compliance. Report to leadership. Make the metric visible.
SLAs without consequences are suggestions. SLAs with executive visibility and accountability are effective. The goal is not to punish engineering teams but to ensure that remediation competes fairly with feature work in the planning process.
Verify fixes automatically
A finding is not closed when someone says “I fixed it.” It is closed when the fix is verified, ideally by an automated test that confirms the vulnerability is no longer exploitable.
For red team findings, this means writing a regression test or a security test that fails before the fix and passes after. This is the same principle as test-driven development: the test is the proof. Without it, you are taking the developer’s word that the fix works, and regressions will reintroduce the vulnerability silently.
Separate the remediation backlog from the feature backlog
Some organizations create a dedicated remediation backlog that engineering teams draw from alongside their feature work: a fixed percentage of sprint capacity allocated to security fixes. This prevents remediation from being perpetually deprioritized by feature work.
The percentage varies. 10-20% of sprint capacity for security and tech debt is common. The exact number matters less than the commitment to reserve capacity at all. A complementary framing that tends to actually move backlog numbers is pairing an uncomfortable stretch goal with a ladder of SMART subgoals, rather than announcing 30-day sweeps and watching them miss.
The red team’s responsibility
Red teams are not blameless in this dynamic. If your findings consistently go unfixed, part of the problem may be how you deliver them.
Write for engineers, not auditors. Include file paths, code snippets, and suggested fixes. Make the finding immediately actionable. The closer the finding is to a diff, the faster it gets fixed.
Prioritize ruthlessly. A report with 47 findings does not get 47 fixes. It gets maybe 5, if you are lucky. Make sure the top 5 are the ones that matter most, and make them impossible to ignore.
Follow up. Do not drop the report and walk away. Check in at 30, 60, and 90 days. Ask which findings are fixed, which are in progress, and which are blocked. Your engagement does not end when the report is delivered; it ends when the findings are resolved.
Build relationships. Engineers are more likely to prioritize findings from someone they know and trust than from an anonymous report. The best red teamers I have worked with spend as much time building relationships with engineering teams as they do breaking into systems. The debrief format also matters: when it doubles as a performance review, admissions stop happening, and the exercise stops teaching anything.
The short version
- The gap between finding and fixing is organizational, not technical. Better reports do not close it.
- If a finding is not a ticket with a scope, an owner, and a deadline, it does not exist to engineering.
- CVSS is a security lens; engineering teams plan against impact to their systems. Translate, or watch your “criticals” get deprioritized.
- The closer a finding is delivered to a diff, and the closer remediation lives to engineering’s normal workflow, the faster it ships.
- SLAs with executive visibility move backlogs. SLAs without consequences are suggestions.
- A fix is closed when an automated test proves the vulnerability is no longer exploitable, not when someone says it is.
That is where the work starts, in the space between the architecture and the operations, and in the planning meetings nobody invites the red team to.