Assign a cloud finding to the team that can change and verify the control most directly responsible for the harmful path. Give a second team an explicit supporting task when the risk crosses infrastructure and application code. Platform commonly owns cloud configuration, deployment policy, identity plumbing, and resource lifecycle; AppSec commonly owns application data flow, authorization requirements, and evidence that a reported path affects a customer. These are starting points, not an organizational law. If neither team can close the path alone, appoint one decision owner and give each change its own completion evidence. For credible active exposure, the on-call team with authority to restrict access should contain it while ownership is resolved; ticket routing must not delay that action.
This is an internal ownership decision. AWS's shared responsibility model explains what AWS and its customer each manage; it does not choose between your AppSec and platform teams. NIST CSF 2.0 asks organizations to establish and communicate cybersecurity roles and authorities under GV.RR. A useful handoff names a control and evidence, not merely a department.
Illustrative case: a public export bucket
Illustrative case, not a live incident: Larch Analytics stores customer export files in an object bucket. A cloud scanner reports that a policy may allow public reads. The bucket policy is generated by Terraform owned by platform. An application worker owned by the product team writes the exports and returns download links. The scanner knows the policy, but it does not know whether the objects contain customer data, whether the policy applies to the actual export prefix, or which environment deployed that Terraform revision.
The security leader gives platform the immediate task of checking and removing unintended public access. AppSec and the product owner determine what is stored, whether application authorization governs link creation, and whether any alternative path still returns another customer's export. The incident owner coordinates impact assessment. If the bucket is intentionally public and holds only approved public assets, the team can reject or reclassify the original privacy claim with evidence rather than silently suppressing the rule.
| Decision point | Question | Primary evidence and likely contributor |
|---|---|---|
| Resource state | Is the reported policy effective on the deployed bucket and prefix? | Platform: effective policy, block-public-access settings, environment and IaC revision |
| Data and path | What writes objects, and are they private customer exports? | AppSec/product: writer, object naming, classification, link generation |
| Actor | Can an unauthenticated or wrong-tenant caller obtain an object? | Security reviewer: authorized synthetic-object check and application route trace |
| Closing control | Which change breaks the harmful path without breaking intended exports? | Platform policy change plus application access change if needed |
| Proof | Does the deployed resource and application now enforce the intended rule? | Release owner, platform, AppSec: new artifact/configuration and observed allowed/denied behavior |
The bucket-policy correction is the most direct response to public object reads. The application review remains necessary because a correctly private bucket may still serve files through an overly permissive signed-link endpoint. OWASP's Authorization Cheat Sheet calls for validating permission on every request. Cloud configuration cannot substitute for that application rule.
Use a four-question routing rule
1. What is the harmful action and the first failing control?
Write one sentence: “An actor with X access could do Y to Z because control C may not stop the path.” Separate the observable cloud state from the inferred application consequence. “Port 443 open to the internet” is a network fact; it may be intentional. AWS documents that security group rules determine allowed inbound traffic, but a rule alone does not tell you whether an application behind it has an authorization flaw.
If the finding is only a hardening recommendation, label it that way. If a customer-data path is plausible but unverified, retain the unknown rather than upgrading a configuration alert to a confirmed breach.
2. Who can change the decisive control?
Find the configuration or code repository, owning service, release authority, and on-call team. Assign the fix owner to the team that can alter and deploy that control. A security leader can own the risk decision without being the fix owner. If a cloud setting is managed in application IaC by a product team, that product team may own the change while platform reviews the policy. If central platform policy causes the exposure, assigning only an AppSec ticket is a dead end.
3. Who can explain the impact?
The team that owns the control may not know whether the affected resource holds private data or is in production. Ask the application owner to map data classification, user actions, tenants, and authorization boundaries; ask platform for account, network and deployment state. The two views should meet in one evidence record. “The scanner found a public bucket” and “the application serves private exports” are separate facts until the bucket and path are connected.
4. Who can verify closure?
Require evidence from the deployed control and the application behavior relevant to the claim. For Larch, platform records the effective bucket policy after the change, while AppSec checks that an authorized user can still retrieve their synthetic export and an unauthorized or wrong-tenant user cannot. A successful Terraform plan without deployment does not establish the runtime state. A blocked public request does not prove the signed-link endpoint is tenant safe. Name one reviewer to reconcile both checks and close, narrow, or keep the finding open.
Resolve the handoff disagreement with two closure conditions
In Larch's synthetic continuation, platform restricts direct bucket access and closes its task. The product team says, “The bucket is private now, so downloads are secure.” AppSec supplies a different path: the application signs a URL for any export ID after login, without checking that the export belongs to the current account. Making the bucket private did not remove the application's authority to sign that link.
The security lead does not reopen the completed policy change as if it failed. Instead, one parent record retains two mechanisms and their own evidence:
| Parent EXP-12 child task | Author / release owner | Closure condition | Current status in example |
|---|---|---|---|
| Direct public object reads | Product team owns Terraform module; central platform owns production deployment | Effective deployed policy restricts unintended direct reads while intended delivery works | Complete for stated prefix/environment |
| Wrong-account signed-link issuance | Export API owner authors code; service release owner deploys | Current caller authorized for stored export/account before any link is issued; legitimate same-account download still works | Open; source path identified, deployment/validation pending |
| Historical exposure assessment | Incident owner | Relevant access records, time range and gaps assessed | Separate investigation |
This assignment distinguishes who writes a fix from who can deploy it. Giving “platform” the whole finding would miss the product-owned module and application defect; giving “AppSec” the whole finding would assign operational work to the verifier. The security lead owns the combined decision, not every implementation task.
The corrected API contract resolves the export through its stored parent/account relationship, checks current download entitlement, and only then issues the delivery mechanism. Previously issued links and their lifetime are a separate residual-access question. Do not claim the code change instantly invalidates every already issued bearer link.
The leadership update reads:
Direct public access to the assessed export prefix is restricted. The parent issue remains open because a separate signed-link route still needs an object-authorization correction and deployment verification. Product owns the code/module changes, platform owns the infrastructure release, and AppSec reconciles the two closure records. Historical access is under incident review; no conclusion about actual disclosure is implied by the configuration fix.
The handoff is finished when each team has a finite deliverable and the parent cannot disappear after only one mechanism is corrected. If the signed-link claim is later defeated by a mandatory downstream ownership check, preserve that counterevidence and close that child on its own merits.
Give the shared record one accountable editor
A parent issue can become as confusing as several disconnected tickets when every team changes its summary independently. Assign one person to maintain the current risk statement and the relationship between child tasks. That person need not approve every code change. Their responsibility is to ensure that “policy corrected” does not become “customer exposure resolved” while the signed-link task remains open.
For Larch, the record editor keeps a small dependency map: direct object delivery depends on the bucket policy; application-mediated delivery depends on export authorization and link behavior; historical impact depends on the available logs and exposure window. Platform can update its own evidence without rewriting the application finding. The API owner can challenge the signed-link claim without erasing the established policy change. The editor reconciles those updates into a clear status for the service owner.
When teams disagree about the first failing control, ask for the smallest piece of evidence that would settle the route. In the synthetic case, the relevant question is whether the link-issuing handler resolves the export's stored account and checks the current caller before signing. A broad debate about whether cloud security belongs to AppSec will not answer it. If the handler delegates that check, follow the mandatory delegate rather than assuming a local missing check proves a flaw.
Handle an ownership gap as an operational fact
Sometimes the authoring repository has no active maintainer, or the team with deployment rights is not the team named in an old service catalogue. Record that gap explicitly and ask the service's accountable owner to assign a temporary fix owner. Do not bounce the alert indefinitely between queues. For active exposure, the authorized on-call team can take a proportionate restriction while the permanent owner is established.
The temporary assignment should state its limits. Platform might restrict a bucket and preserve intended export availability without taking permanent ownership of the product's authorization code. AppSec might supply a source-supported failure description without becoming the product's release manager. These boundaries make the handoff practical and help prevent an emergency arrangement from becoming an invisible long-term responsibility.
After closure, change the ownership map at the level that caused the confusion. If product owns the Terraform module but platform releases it, record both roles. If shared download middleware serves several products, identify who approves changes to that middleware and who validates the affected callers. Do not merely add another broad “security owner” field that points back to the same queue.
The next similar finding should arrive with a route to implementation and a distinct route to verification. That is the measurable outcome of this exercise: less time spent finding authority, while each completed control still has evidence for its own result.
The rule has limits. Some teams share repositories or have different service contracts; a cloud resource may be controlled by a vendor, a central security group, or an application team. A source-only review cannot establish the effective live policy, and a cloud scanner cannot by itself prove the application's business impact. Resolve ambiguous cases through the control and evidence, then update the ownership map so the next similar finding routes faster.
For the next disputed cloud alert, fill in the harmful action, decisive control, fix owner, impact owner and closure evidence before assigning a ticket. If the disputed control is an IAM grant to tenant data, follow the temporary credential review. If the cloud alert concerns a deployed image, use the container image context guide.