Web & API · Merchant platform v4.2
Countermind report
The report
A finding is a start. A decision is the outcome.
A useful report helps leadership understand the risk and gives engineering enough context to act. Every finding in it was reproduced and signed by a Zaaf researcher.
Executive summary
Scope, material findings and what to do first.
- AI observations
- 486
- Human-verified findings
- 15
- Critical
- 1
One cross-tenant read affects every merchant. Fix it before the next release.
ZF-0147-02Critical
Merchants can read each other's settlements
Critical · CWE-639 · CVSS 9.6
- GET /v2/merchants/MRC-58213/settlements HTTP/1.1
- Authorization: Bearer ██████████████████
- HTTP/1.1 200 OK
- {"merchant_id": "MRC-58213",
Request, response, impact, reproduction and fix on one page.
Human-verifiedAI-found ZF‑0147‑02 2026‑09‑28
Coverage and limits
What was tested, what was not, and why.
- Tested
- Settlements, payouts, member roles
- Not tested
- Card vault (third party, excluded)
- Limitation
- No production write actions
- Retest
- Agreed for critical and high
Finding anatomy
One finding. Every part has a job.
This is ZF-0147-02 from page 03, taken apart. Each part is on the page because someone needs it to make a decision.
-
01
Identity
A stable ZF number, issued once. It follows the finding through triage, fix and retest, so every conversation points at the same record.
Read first bySecurity ownerEngineering
-
02
Severity
The plus is the scale. Each filled arm is one step of impact, and four filled arms mean Critical. Class and CVSS sit beside it for your tooling.
Read first byLeadership
-
03
Plain-language title
What an attacker can do, in words a board can repeat. If leadership reads one line of the finding, this is the line.
Read first byLeadership
-
04
Request and response
The exact request and the response it returned, with secrets redacted. Engineering can replay it and see the same 200 OK.
Read first byEngineering
-
05
Impact
The demonstrated consequence, counted where it can be. Here, 1,284 merchants. Assumptions and limits are stated, never implied.
Read first byLeadershipSecurity owner
-
06
Fix
Guidance aimed at the mechanism that failed, not a generic best practice. One change, specific enough to review.
Read first byEngineering
-
07
Human-verified
A Zaaf researcher reproduced it in two clean runs and signed it. Without this band, a finding does not enter the report.
Read first bySecurity owner
Assembled
Seven parts. One page.
Put back together, the parts read as one finding: leadership decides, engineering fixes, the security owner closes it.
Make the risk understandable. Make the next step practical.
-
Leadership
For prioritisation- Cover (not a focus)
- Summary
- Finding (not a focus)
- Appendix
A clear view of the work.
Decision-makers need the material findings in context, not a raw alert feed.
Parts read first
- 02Severity
- 03Plain-language title
- 05Impact
- Matters most
- The scope, the limits and the business consequences of reviewed findings.
- Looks for
- A clear line between demonstrated behaviour and broader assumptions.
- Leads to
- An informed discussion of priority, ownership and the next action.
-
Engineering
For remediation- Cover (not a focus)
- Summary (not a focus)
- Finding
- Appendix (not a focus)
Enough detail to evaluate the fix.
Engineers need the affected boundary and its preconditions.
Parts read first
- 01Identity
- 04Request and response
- 06Fix
- Matters most
- Affected components, relevant roles and reproduction context.
- Looks for
- Expected versus observed behaviour, with the request and the response.
- Leads to
- A practical remediation discussion grounded in the demonstrated mechanism.
-
Security owner
For follow-through- Cover (not a focus)
- Summary (not a focus)
- Finding
- Appendix
Keep the closure decision grounded.
A fix and a verified outcome are related, but they are not the same record.
Parts read first
- 01Identity
- 05Impact
- 07Human-verified
- Matters most
- Which changes and conditions were included in the agreed retest.
- Looks for
- The observed result and any remaining limits or untested areas.
- Leads to
- A scoped closure decision, not a declaration that the whole system is secure.
A finding should explain more than what failed.
-
01
Engagement context
Includes
Agreed assets, environments, roles, exclusions and constraints.
Why it matters
The reader knows what the Countermind represents.
-
02
Technical findings
Includes
Mechanism, prerequisites, affected components and supporting observations.
Why it matters
Engineering can evaluate the behaviour in the right context.
-
03
Impact and priority
Includes
Demonstrated consequences and the assumptions behind them.
Why it matters
Severity never stands in for an explanation of impact.
-
04
Remediation
Includes
Guidance that addresses the affected behaviour or trust boundary.
Why it matters
The next step is tied to the mechanism.
-
05
Coverage and follow-up
Includes
Untestable areas and the result of any agreed retest.
Why it matters
Missing coverage is never mistaken for a clean result.
Severity you can read at a glance.
The Zaaf severity mark is the plus itself. Each filled arm is one step of impact.
-
Critical
4 of 4 arms
Direct, low-privilege access to the data or money of many customers.
-
High
3 of 4 arms
Loss of data, money or privilege for a single customer or account.
-
Medium
2 of 4 arms
An issue that grows when combined with another flaw, or exposes limited data.
-
Low
1 of 4 arms
A gap that makes an attacker's job easier but has limited impact alone.
-
Info
0 of 4 arms
No direct risk; a recommendation that strengthens defences.
A change is a proposal. A retest is an observation.
Retesting happens only as agreed. Its result is tied to the version, the conditions and the behaviour assessed.
-
01
Share the change
Send the fix, the version and any changed test prerequisites.
Your context -
02
Agree the retest
Confirm which findings, environments and scenarios will be revisited.
Defined follow-up -
03
Record the outcome
The observed result, unresolved concerns and testing limits are written down.
Reviewed status
LimitA scoped retest does not establish that unrelated behaviour, or the whole application, is free of vulnerabilities.
Assessed by Zaaf.
After delivery you may show the Assessed by Zaaf badge, with the month of the work. It states that a Countermind took place, not that a system is secure.
Use of the badge, names and logos follows the agreed terms.
See the structure. Ask for a shareable sample.
The pages above describe the format. They are not a customer report, a measured finding or evidence of a completed engagement.
Straight answers
Can you share a sample report?
Ask for a shareable sample during the scoping call. The layout on this site is illustrative, not an actual customer report.
Will the report satisfy our customer's security review?
Acceptance is not guaranteed. Share your customer's format and coverage requirements before the work starts so we can assess fit.
Is a retest included?
Only where agreed. Retest scope, timing and terms are defined in the engagement.
Is the report written by AI?
No. Agents support the investigation; researchers write, verify and sign everything you receive.
Can we publish the report?
Disclosure and redistribution follow the agreed terms. Do not assume a private report is approved for publication.
Bring your scope. Let's plan the Countermind.
Thirty minutes with a Zaaf researcher. You bring one scope; we show you what a Countermind would look at first.
- Next step
- 30-minute call
- With
- A Zaaf researcher
- You bring
- One scope
- Runs before you agree
- Nothing