Read the report

The report shows the repository, branch, commit, and scope of the audit. Open it from Audit > Audits. The How this audit ran section gives the details of the run.

Parts of a finding

Each finding shows these parts:

• a priority, from P0 (Critical) to P3 (Low)
• its state: Confirmed issue, Might be a problem, Informational flow, or Resolved. A finding that might be a problem can show its priority without a state.
• What to do: the fix or the review to do
• Where it is: the files and lines
• Why it matters: the data flow or control that it affects
• How this was checked: the evidence

Filter and share findings

Filter findings by Priority, State, or file path. The State filter has Confirmed issues, To review, and Observations. Select Copy as Markdown to share the findings.

Decide what to do

Start with the Critical and High findings. Priority shows potential impact. It does not prove a legal violation. Read the cited code and confirm your assumptions with the code owner.

Code Audit findings also go to the Inbox. There, mark each finding as False positive, Accept risk, or Resolve.

If the audit did not investigate all of the code, the report says so. Run the audit again before you treat that report as clean.

What a finding looks like

This is an example:

Customer email addresses go to application logs during checkout (High priority)

apps/shop/src/checkout/confirm.ts:84 sends the full customer object, with email and shippingAddress, to the request logger. The logger sends logs to a third-party observability tool. Personal data leaves the application outside the documented data flow.

Cited evidence: the call to the logger, the logger configuration, and the observability destination.

What to do: log only the order ID, or remove the personal fields. Check how long the observability tool keeps logs.

A real finding has the same parts. It has a plain-language claim, a priority, the files and lines, the cited evidence, and what to do.