This essay draws on recurring patterns across security and engineering work rather than one identifiable engagement. Product and client details are intentionally omitted; the endpoint examples are illustrative and are labeled as such.
The gap between a red team finding and an engineering fix is organizational. The security team cannot close it alone, and the red team cannot close it by writing better reports. It closes when remediation enters the same ticketing, ownership, testing, and planning system used to ship features.
A recurring pattern looks like this: a red team engagement ends, the report lands with dozens of findings, and the artifact goes into a shared drive. Months later, another test finds some of the same issues. The sequence is illustrative, but every handoff it describes is a real place where remediation can lose ownership.
The organizational machinery that converts findings into fixes is what breaks down, not the red team’s work: 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.
For example, an illustrative finding that says “SQL injection in the user search endpoint (CVSS 9.8)” tells an engineer almost nothing. One that identifies an affected path and line, shows the unsafe query construction, and supplies a failing regression test 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 high CVSS base score on an isolated development service does not necessarily create more business risk than a lower-scored flaw on the production login path. CVSS describes technical severity; it does not encode your deployment topology, data value, compensating controls, or recovery cost. Engineering and security need a shared prioritization decision that keeps the base vector visible while adding the environment around it.
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 highest-leverage change most security programs can make is turning every remediation action into 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. 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
For small, well-understood defects, one effective delivery method is a branch or pull request. The red team can pair a finding with a failing test, a candidate fix, or both, and let the engineering team review it through their normal workflow.
This is not always possible or appropriate. Complex architectural issues do not fit in a PR, and an independent assessor may be expected to demonstrate the defect without making an unsupervised production change. Use the closest safe artifact to engineering’s workflow: a reproducible test, a minimal patch, or precise acceptance criteria.
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 think adversarially. Reporting lines should preserve the independence the role needs, but the right arrangement depends on the organization’s structure and escalation paths. Done well, the embed shortens translation and gives both teams a trusted counterpart.
Track remediation with SLAs
Define remediation targets from severity, exposure, exploit activity, asset value, and operational constraints. A program might start with 7 days for urgent internet-exposed findings, 30 for high-risk findings, and 90 for bounded medium-risk work, but those numbers are policy choices rather than universal constants. Track both compliance and the age of approved exceptions.
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 remediation has been independently verified. An automated regression test is strong evidence that the demonstrated path no longer works; it is not proof that every exploit path or variant is gone.
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 should come from backlog age, product risk, and delivery capacity. The exact number matters less than making the reservation explicit and revisiting it when risk accumulates. A complementary framing that can make the work manageable 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 findings for engineers, not auditors: include file paths, code snippets, and suggested fixes, and make the finding immediately actionable. The closer the finding is to a diff, the faster it gets fixed.
A report with 47 findings gets maybe 5 fixes, if you are lucky, so prioritize ruthlessly. Make sure the top 5 are the ones that matter most, and make them impossible to ignore.
Check in at 30, 60, and 90 days rather than dropping the report and walking away. Ask which findings are fixed, which are in progress, and which are blocked. Your engagement ends when the findings are resolved, not when the report is delivered.
Engineers prioritize findings from people they know and trust over an anonymous report, so build relationships. 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 report is only the first artifact. Remediation becomes real in the planning meeting where someone accepts the ticket, names the tradeoff, and agrees on how the fix will be verified. If the red team is absent from that conversation, the most important part of the engagement is happening without them.