Client web app

Summary

Of 24 possible lanes (2 in-scope hosts × 12 lanes), 8 were opened and 4 are receipted: every checklist item has evidence or a written reason, the receipt matches the ledger, and a named person reviewed the lane and closed it. No receipts are void. Lanes that were not opened were not tested.

Coverage matrix

Each in-scope host against each lane of the methodology pack.

Receipts

A receipt is the SHA-256 of the lane’s manifest: its items, their states and reasons, and the hashes of its evidence. A person issues it when they close the lane. A signature ties it to the reviewer’s key; a timestamp from an independent authority shows it existed at that time.

4 opened lanes have no receipt yet.

Change history

Every change to this engagement’s scope and rules, settings, roles and authorization, and to the accounts of the people who work on it or signed its receipts, from the server’s audit log. Each entry is hash-chained to the one before it, like the evidence; the verifier checks the links and uses them to say, for each receipt, which scope was in force and whether its signer held the reviewer role when it was issued.

10 engagement entries and 4 person entries. Entries made by “recorded when the audit log was added” are the state at that time; who set it before then is not known. Passwords are never recorded, only that one was set.

How to verify

Anyone can check this report without AttackLedger, the tester’s server or a network connection. The verifier is one file, verify_report.py, and needs only Python 3 and its standard library.

The quickest way: drop this file, HTML or JSON, on attackledger.com/verify. The same checks run in your browser, and the file is not uploaded.

1. Get the files

Save this report as JSON (or keep this HTML file: it embeds the same report). Download the verifier and the timestamp root it trusts from attackledger.com, which publishes them independently of the server that made this report:

• https://attackledger.com/verify_report.py
• https://attackledger.com/digicert-trusted-root-g4.pem, saved in a folder named tsa-roots next to the script

If you have an account on the AttackLedger server that made this report, its Report and Verify tabs offer the same files as one download, attackledger-verifier.zip (on that server at /api/verifier/attackledger-verifier.zip), and show each file’s SHA-256. Before you rely on a copy from the tester’s server, compare its SHA-256 with the copy from attackledger.com:

sha256sum verify_report.py        # or: shasum -a 256 verify_report.py

2. Run the verifier

python3 verify_report.py report.json --tsa-root <root.pem>

For example, with the DigiCert root, or with this HTML file:

python3 verify_report.py report.json --tsa-root tsa-roots/digicert-trusted-root-g4.pem
python3 verify_report.py report.html

Roots in tsa-roots/ next to the script are trusted without --tsa-root; pass it for any other authority. Running python3 -I keeps Python from loading modules from the current folder.

3. Read the result

Each check prints PASS or FAIL, or SKIP when there was nothing for it to check, such as signatures in a report whose receipts carry only a name. A skipped check neither passes nor fails. The last line says Verified. and the exit code is 0 only if no check failed. Add --require-signatures to fail any receipt that is not signed. NOTE lines are information, such as who signed and which receipts are not timestamped.

Where the timestamp root comes from

tsa-roots/digicert-trusted-root-g4.pem is DigiCert Trusted Root G4, the root of DigiCert’s public timestamp service (timestamp.digicert.com), taken from the macOS root store and matched against DigiCert’s download. Before you rely on it, compare its SHA-256 fingerprint with your operating system’s root store or DigiCert’s site:

552F7BDCF1A7AF9E6CE672017F4F12ABF77240C78E761AC203D1D9D20AC89988

Tie keys to people

A valid signature proves the holder of that key signed. The key log shows when each key was registered to its signer and how; the server never holds a private key, but whoever runs it could register a new key for someone, and that key would appear here with its own registration. For high assurance, ask each signer for their key fingerprint through a channel you trust and compare it with the one in Receipts. To make sure this is the report you were sent, compare the report body SHA-256 on the cover with the value the tester gave you.

Control evidence

Indicative mapping of tests to controls; not a compliance determination. Reviewed against public sources by Claude on 2026-10-09; not reviewed by a qualified assessor (QSA, ISO lead auditor or DORA TLPT authority).

Evidence strength:

• Full: The result alone answers the control's test; nothing else is needed.
• Partial: The result answers a defined part of the control's test; the rest needs other evidence.
• Supporting: The result is relevant and can corroborate other evidence; it does not answer the test.

Item detail

api.client.test · Information gathering Receipted

api.client.test · Input validation In progress

app.client.test · Information gathering Receipted

app.client.test · Configuration Receipted

app.client.test · Authorization Receipted

app.client.test · Authentication In progress

app.client.test · Session management In progress

app.client.test · Input validation In progress