Assign the person or team that can change the failed control, then name the people needed to review and release it. The file owner, service operator and product decision maker may be different. Start with a verified finding and trace the harmful path to its enforcement point. Check the current code ownership map and ask the candidate owner to confirm they can implement the fix. Give them a short evidence packet: affected revision, harmful action, failed rule, relevant path, desired behavior and acceptance check. If ownership is ambiguous, keep the finding with a security dispatcher and resolve the boundary; do not close or broadcast it to every developer.
A CODEOWNERS file is a useful lead, not a complete answer. GitHub's code owner documentation explains how it requests pull-request reviews for matching files. It does not establish who can change a shared policy, configure a gateway or approve a production rollout. The right remediation owner is the team that can make the failed rule hold across the affected path.
Trace the ownership problem in one case
Illustrative case, not a real customer finding: Meridian Orders receives payment-provider webhooks. An independently reviewed source finding at revision M9 shows that the order handler accepts a delivery and marks an order paid before any signature check is applied on that path. The plausible harmful action is a forged delivery causing an unpaid order to enter the paid state. The example is source-traced; it does not claim that a forged delivery was sent to a live service.
The first file named in the finding is services/orders/paid_event.py, owned by the orders team. The shared webhook adapter lives in services/ingress/webhooks/, owned by the API platform team. Platform operations owns secret distribution and route configuration. The orders team understands which payment events may change business state, but a fix placed only in paid_event.py might leave other webhook consumers accepting unsigned deliveries. Conversely, a generic signature check in the shared adapter may need provider-specific input from orders. OWASP's Webhook Security Cheat Sheet treats authenticating deliveries, secret handling, replay protection and idempotent processing as distinct parts of the receiving workflow. That is a useful map for assigning work, not a reason to prescribe one patch without inspecting Meridian's design.
For this case, the AppSec lead assigns the API platform team as the primary code owner for the missing verification boundary, makes the orders team the domain reviewer for state transitions, and asks platform operations to verify secret and rollout configuration. One named person coordinates the work item. A service owner confirms that the route uses the shared adapter in the target deployment. Those assignments are an editorial choice for this fictional architecture; in a different system, the orders team might own the only safe enforcement point.
Resolve a justified return instead of bouncing the ticket
Platform returns the initial assignment with a concrete reason: its shared adapter receives parsed JSON and no longer has the provider's original request representation. Orders owns the provider-specific HTTP endpoint before parsing. In this constructed architecture, the safe immediate verification point may therefore be in Orders, even though Platform owns the shared adapter.
This is a real design constraint to inspect. For example, Stripe's webhook documentation requires the unchanged raw request body for signature verification. The provider in a real finding must supply its own exact verification contract; do not reconstruct signed bytes by serializing a parsed object and assume equivalence.
Parsing for routing is not itself proof of a bypass if the exact original body is retained and verification occurs before any effect. The defect here is losing the signed representation and accepting an event without verification. The teams compare two designs:
| Design | Required change | Consequence |
|---|---|---|
| Shared adapter verifies every provider | Preserve raw bytes and required signature metadata through ingress; add provider-specific verifier selection; review all consumers. | Broader future boundary, but larger compatibility and rollout scope. |
| Orders verifies its provider before parsing and forwarding | Use the provider's supported verification procedure at the raw-body endpoint; reject before paid-state mutation. | Smaller immediate repair for MO-63; other providers retain their own review obligations. |
They choose the second for the current finding and create a separate architecture task to evaluate the shared interface. Orders accepts the implementation. Platform reviews that verified context cannot be forged by an alternate caller and supplies the ingress mapping; operations supplies endpoint-secret configuration and rollout evidence; AppSec retains the security decision.
The revised first task is: “Trace raw request body and signature metadata through the Orders endpoint, verify the preserved raw body before dispatch or state mutation under the provider's actual API, and account for the legacy route.” This is a bounded task the new owner can execute. It does not imply signature validation alone establishes event freshness, idempotency or the legitimacy of every state transition.
One Orders developer cannot open the restricted evidence link. The dispatcher requests the necessary repository/report access through the normal authorization process and keeps a source-free routing summary in the ticket. The team does not paste raw requests, signing secrets or source into a broad channel to speed assignment. Until access and acceptance are confirmed, the finding remains with the dispatcher as open work.
The result is an architecture-grounded ownership change: not “Platform refused,” but “Orders retains the required verification inputs at the enforceable boundary; Platform is a necessary reviewer.”
A filled handoff the developer can act on
Finding:
MO-63— A forged payment delivery could mark an order paid.Status: Approved and open at repository revision
M9; source-supported path, no live exploit asserted.Entry and effect: Public payment webhook route → shared adapter → order handler → paid-state transition.
Failed rule: The route should verify the provider's delivery authenticity before business-state changes; the traced path does not apply that check.
Primary owner: Orders team, after the raw-request boundary review; the current endpoint retains the inputs required for provider verification.
Reviewers: Orders team for accepted event types and state transitions; platform operations for secret configuration and rollout.
First task: Verify the provider delivery using the preserved raw body at the Orders endpoint before state mutation; map legacy bypasses with Platform.
Acceptance evidence: At a new pinned revision and authorized staging deployment, a correctly signed synthetic delivery follows the intended path; an invalid delivery is rejected before order mutation; replay and duplicate handling are reviewed separately.
Unknown to resolve: Whether a legacy webhook route bypasses the shared adapter.
Next checkpoint: Orders returns the endpoint patch plan; Platform supplies the binding and legacy-route map.
The packet names the business effect early and pushes technical details to the team that needs them. It also separates the patch acceptance check from the unresolved legacy route. A proposed patch cannot be treated as complete until that route is accounted for.
Require an accepted handoff, not a forwarded ticket
A handoff is complete when the receiving owner has the authority, evidence and first task needed to act. Forwarding MO-63 to Orders changes the assignee but does not establish those conditions. Ask the named developer to confirm that they control the raw-body endpoint, can inspect the relevant evidence and understand which legacy route remains unresolved.
For this case, the acknowledgment could read:
Orders accepts the endpoint verification change. We retain the original body and will use the provider's verification contract before business mutation. Platform will supply the active ingress mapping and review alternate callers. Operations owns endpoint-secret configuration and rollout evidence. We will return the proposed revision and the signed/invalid synthetic delivery check plan.
The acknowledgment exposes dependencies without making every participant a co-owner of the same undifferentiated task. If operations cannot supply the configuration in the intended window, the coordinator can adjust the plan before code review is mistaken for completed remediation.
Keep reassignment evidence concise
When ownership changes, retain the reason. “Orders has the original verification inputs; the shared adapter receives parsed data” explains the decision and helps the next dispatcher. “Platform declined” records only social friction and encourages the same mistaken assignment next time. A legitimate return should name the missing authority or input, and preferably the team that has it.
If no team clearly owns the boundary, the engineering manager should assign temporary coordination and a decision deadline. That is an organizational gap to resolve; it does not make the technical finding disappear. The security reviewer can preserve the harmful path and recommend proportionate containment while the implementation owner is chosen.
A cross-team repair should also define the final evidence bundle. Orders supplies the endpoint source, platform the route and alternate-caller assessment, and operations the deployed configuration. The coordinator assembles the references into one closure note so a reviewer does not need to chase three separate “done” messages. Each team's completion is useful, but the finding closes only at the stated end-to-end scope.
After the repair, improve the ownership map at the level that failed. If CODEOWNERS correctly identified file reviewers but nobody knew who controlled verification inputs, adding more file patterns may not solve the problem. Record the webhook boundary and its operational owners in the existing service documentation. This makes the next security handoff faster without turning one incident into a new organization-wide process.
Use an ownership map when the first file misleads
| Role in Meridian's path | Team | Why involved | Decision or output |
|---|---|---|---|
| Finding coordinator | AppSec lead | Preserves verdict and scope, controls reassignment | One current owner and review checkpoint |
| Fix owner | Orders | Owns provider endpoint with raw verification inputs | Endpoint patch and accepted first task |
| Boundary reviewer | API platform, with Orders domain reviewer | Owns adapter binding and alternate ingress; Orders owns event/state semantics | Confirm verification precedes mutation and legacy entries cannot bypass it |
| Deployment owner | Platform operations | Owns secrets and route configuration | Authorized staging and rollout evidence |
This map is more precise than adding all four teams as undifferentiated assignees. If the fix instead belongs in an orders-specific adapter, update the map and document why. If two teams disagree, have them walk the actor-to-effect path together and decide where the invariant “unverified deliveries cannot change payment state” is enforceable. Keep the AppSec lead accountable for the finding decision, not for writing another team's code.
Once Orders accepts the repair, ask it to confirm the first concrete action and the artifacts it needs. “Orders owns this” is less useful than “Orders will inspect the provider endpoint's raw verification inputs and request the alternate-ingress map from API platform.” The latter exposes a missing dependency before a developer begins changing the wrong layer.
Keep acceptance separate from agreement with every technical detail. The owner can accept responsibility for examining the endpoint and still challenge the proposed implementation. If new evidence shows the boundary belongs in the adapter, update the accepted task and coordinator together. Do not silently move the issue between teams or leave both believing the other now owns it. The payment-state invariant and current evidence should survive the transfer unchanged.
When the correct owner lacks access to the evidence, use the organization's authorized access process rather than copying restricted reports into a broad chat. When no eligible owner exists, leave the task in a restricted dispatch queue with a named escalation owner. A quiet backlog entry with no assignee is not a handoff. For the next finding, fill the four-role map before you create the developer task. Then use the security fix ticket template for the full work item, and the patch review checklist once the owner proposes a change.