Use this triage decision path
Start with a reproducible case in a controlled account. Record the route, role, data object, deployed version, and state before and after the request. If the case cannot be reproduced, keep it in verification with an owner instead of marking it false.
| Item | Check or owner | Evidence |
|---|---|---|
| Is it reproducible? | Tester | Keep request and expected result |
| Can it affect money or data? | Product owner | Trace impact path |
| Is the path exposed now? | Operations | Check deployed versions |
| Who owns the fix? | Engineering lead | Set target and retest date |
Test and retest
Ask whether the flaw reaches funds, account takeover, private data, or service loss. Trace the shortest realistic path. Assign the fix owner and retest owner, then verify the released build. A patch in source does not prove the exposed service changed.
Evidence to keep
A good triage record distinguishes evidence from assumptions. “Two requests were sent” is evidence; “two charges were made” needs provider and ledger proof. Ask the reporter for a safe operation ID and test window, then reproduce in a sandbox. If the result points to live fraud, preserve logs and follow incident steps before changing data. The team should not run a noisy exploit against customer accounts just to fill a severity field. Close the report only after a retest on the release that customers use.
Triage one vulnerable release
Synthetic example: a library flaw affects the image service, and another affects the payment API. Record the package, version, reachable route, deployed build, and proof for each. The payment API receives signed customer requests and can alter saved payees; the image service serves public files and has no payment credentials. Check whether the affected code path is actually used before setting an owner and deadline. The finding must still be tracked if reachability is unclear.
Keep severity and release priority in separate fields. FIRST’s CVSS consumer guide explains how local threat and environment facts can refine a Base score. A temporary gateway rule may lower exposure, but it does not fix a library that another route can call. Record the rule, expiry, and test. After patching, confirm the deployed version and rerun the request that proved impact. Close the issue only when the vulnerable path and nearby paths fail safely.
Move the report through clear states
Use intake, verification, confirmed, contained, fixing, retest, and closed as distinct states. A report lacking provider IDs stays in verification with a named test and due time. A confirmed finding enters fixing with the affected build and owner. A temporary gateway rule moves exposure into contained only after a test proves the rule; it does not close the code defect.
For a duplicate-transfer report, reset one seeded payment and preserve its operation key. Send the same instruction twice after a lost response. Inspect provider transfer IDs, committed intent, journal, and notification outcome. Repeat with two distinct keys as a separate case: those are new requests and must face funds and limit checks. This prevents a test from confusing duplicate delivery with two valid customer decisions.
Escalate live loss indicators to the incident owner immediately, preserve logs, and apply an approved containment action while reproduction continues. For a library issue, record the loaded package version and the route that reaches vulnerable code. “Cannot reproduce” alone does not prove the route is safe. After repair, capture running API and worker versions, the original denial test, and allowed behavior.