How to triage security findings before changing code

A finding is a claim about a particular input and configuration. Before deciding what to fix, record the repository, branch or commit, analysis settings, and any excluded code. Results from an older revision may describe a problem already changed; results from a partial scan may omit relevant guards or dependencies.

Read the summary together with the indicated location and supporting context. Distinguish what the tool observed from what it inferred. If a claim lacks enough evidence for a decision, record that gap and request the missing context. Do not turn an uncertain result into either a confirmed incident or a dismissed false positive merely to clear a queue.

Static analysis can identify suspicious patterns without knowing all runtime behavior. Review the surrounding logic and the application’s requirements. A risk can depend on permissions, data ownership, configuration, or a call path that the scan did not fully resolve. Answer these questions through an authorized code and configuration review.

• Evidence: which part of the code or configuration supports the finding?
• Applicability: does the affected behavior exist in the revision being shipped?
• Reachability: can the relevant application flow reach it under the intended permissions?
• Impact: which users, assets, or trust boundaries could be affected?
• Existing controls: is protection enforced consistently on the actual path, rather than only assumed?
• Uncertainty: what is still unknown, who can answer it, and when will it be reviewed?

The public Hi AUDIT WebMCP demo includes sample finding HA-103, titled “Invoice lookup misses tenant boundary.” It illustrates an authorization review: a record operation must respect the authenticated tenant’s ownership rules. This is synthetic demonstration data, not a result from a customer repository or evidence of a live incident.

The reviewer should inspect where tenant identity comes from, where ownership is enforced, and whether every relevant record access follows the same policy. Assign the change to the team that owns that boundary. A remediation should enforce the trusted tenant context and include negative authorization coverage in the team’s own test environment. Review the surrounding operations as well as the line highlighted by the tool.

Keep severity and delivery priority separate. Severity summarizes the finding’s possible consequence; priority also reflects exposure, affected assets, compensating controls, and the cost of delaying remediation. Use the team’s own response policy instead of copying a generic deadline into every issue.

After a proposed fix, confirm that it enforces the intended requirement and does not break legitimate use. Review the change, run the relevant tests, and repeat the analysis where appropriate. A disappearing warning alone does not establish that the security boundary is correct. Retain the decision and evidence so future reviews can distinguish a fixed issue from a suppressed rule.