AUDIT REPORT — [ CLIENT PROJECT ]

Notice on execution privacy

Nothing from the files, the data or the findings was sent to the consultant beyond the step progress and the session identifier.

The plan, counted

final plan: 7 fronts + 3 adversarial skeptics · executed: 7/7 + 3/3 · added: 0 · removed: 0

The plan is counted before execution, from what actually exists in the target — it is not a generic checklist. Growing during the audit is normal and gets recorded; shrinking requires a written reason. That is what stops an audit from ending simply because it got tired.

• ✅ Front 1 — [ subsystem ] — 31 files, 25,228 lines
• ✅ Front 2 — [ subsystem ] — 31 files, 23,924 lines
• ✅ Front 3 — [ subsystem ] — 29 files, 23,546 lines
• ✅ Fronts 4 to 7 — ▉▉▉▉▉▉▉▉▉▉▉▉

Scope — what was NOT covered

A mandatory section. A report that only lists what it found leaves the client with no idea where nobody looked.

• Folders outside the scope declared in the form — they were not read. (▉▉▉▉▉▉▉▉▉▉▉▉)
• Build artifacts and third-party libraries — excluded by rule, with the list named one by one.
• Execution: 100% read-only. Where the next step would require running the system or observing the live state of the environment, the report writes “client to confirm in the environment” — and states exactly what is left to measure and who measures it. It does not presume.

Every finding carries an evidence label: [MEASURED] (ran it and have the output) · [ANALYSED] (derived from reading code, without executing) · [ESTIMATED] (order of magnitude — never supports severity). In this model, every finding is [ANALYSED].

Scoreboard

Illustrative figures. We do not charge per finding — paying by quantity is the incentive to inflate the list.

Cross-cutting counts

What only shows up when you look at the whole — and what changes the client's remediation plan, because it groups dozens of findings into a few root causes:

• “▉▉▉▉▉▉▉▉▉▉▉▉ of ▉▉▉▉▉▉▉▉▉▉▉▉ modules use the weak path through ▉▉▉▉▉▉▉▉▉▉▉▉”
• “▉▉▉▉▉▉▉▉▉▉▉▉ of ▉▉▉▉▉▉▉▉▉▉▉▉ configuration files with permission ▉▉▉▉▉▉▉▉▉▉▉▉”
• The 45 occurrences reduce to 4 structural patterns — fixing by pattern closes several findings at once.

Routing by responsible party

Anatomy of a finding

Every finding carries the same fields, always. That is what makes the report checkable by the client's own team without depending on us:

Discarded at verification

The suspicions we raised, investigated and knocked down — each with its reason. It is the proof that the list was not inflated, and it is the part no scanner is able to write.

• D-1 — suspected ▉▉▉▉▉▉▉▉▉▉▉▉. Traced to [ file ]:48-52: the values come from the server and the user controls only the index. Discarded.
• D-2 — ▉▉▉▉▉▉▉▉▉▉▉▉. The block is commented out, it never runs. Discarded.
• D-3 — ▉▉▉▉▉▉▉▉▉▉▉▉. Mechanism confirmed, the full consequence would require running it. Downgraded to “client to confirm in the environment” instead of becoming a critical.

A downgraded finding is not thrown away: what stands regardless of measurement stays on the record.

What is that way on purpose

Whatever the client declared as a deliberate decision in the scope form goes here — checked against the code. The declaration changes how it is read; it does not make the audit skip anything. A divergence between what the system declares and what it does is a finding.

Prioritised recommendations

• Do now, before the next release: ▉▉▉▉▉▉▉▉▉▉▉▉
• Next sprint: ▉▉▉▉▉▉▉▉▉▉▉▉
• Next quarter (structural): ▉▉▉▉▉▉▉▉▉▉▉▉

How this report is delivered

• Markdown — the source of truth, versionable alongside the code.
• Self-contained HTML — nothing external, ready to become a PDF (Ctrl+P → Save as PDF).
• In Portuguese or English, at the client's choice.
• Written on the client's machine. We receive no copy, and we never publish anyone's report.