AttackLedger coverage report

Client web app

Engagement type: Penetration test
Methodology pack: Web application pentest (OWASP WSTG), version 0.1
Generated: 2026-10-09 17:16:37 UTC
Report format: attackledger-report/2
Report body SHA-256: 6939c0a2553829d2d38f382e13b81fcf7e599c29e214393f4fc0b566dc4f4b0a

Summary

2In-scope hosts

5 of 6Lanes receipted, of those opened; 24 possible

43Items with evidence

8Items not applicable, with a reason

3Items still open

5 of 5Receipts signed with a key; 5 timestamped

Of 24 possible lanes (2 in-scope hosts × 12 lanes), 6 were opened and 5 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.

What this report proves. It is a record of what was tested, not a judgement of how well. It shows which checklist items were recorded as tested or not applicable, which evidence was attached to each, who closed each lane and when, and that none of this changed after it was recorded: the evidence is hash-chained, signed receipts carry a signature from the reviewer’s own key, timestamped receipts carry a token from an independent timestamp authority, and anyone can re-check all of it offline.

It does not prove that the tests themselves were thorough or correct, that untested lanes or hosts are free of issues, or that a signing key belongs to the person named; compare key fingerprints with the signers for that. It is not a list of findings.

Scope and authorization

Authorization recorded by

demo operator

Recorded at

2026-10-09 08:13:49 UTC

Policy or statement of work

https://example.com/statement-of-work

In scope (rules)

api.client.test
app.client.test

Out of scope (rules)

None

Rate limit

5 requests per second

Identification header

X-Pentest: client-engagement

User agent

Not set

Separation of duties

Off

Signatures required

Yes: a receipt needs a signature from the reviewer’s key

Evidence redaction

On: credentials, and email addresses and card numbers in captured responses and files, are replaced by a hash marker before raw evidence is stored; each entry says what was redacted

Retention

Content kept until an owner deletes it

The authorization entry is the tester’s own statement that they were permitted to test, with the policy or statement of work it refers to. Recon and agent runs only reach hosts that match these rules, at this rate.

Coverage matrix

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

Receipted every item resolved, reviewed and closed Void receipted, then the ledger changed In progress opened, not closed Not opened not tested

Lane	`api.client.test`	`app.client.test`
Information gathering	Receipted	Receipted
Configuration	Not opened	Receipted
Identity management	Not opened	Not opened
Authentication	Not opened	In progress
Authorization	Not opened	Receipted
Session management	Not opened	Receipted
Input validation	Not opened	Not opened
Error handling	Not opened	Not opened
Cryptography	Not opened	Not opened
Business logic	Not opened	Not opened
Client side	Not opened	Not opened
API	Not opened	Not opened
Receipted	1 of 12	4 of 12

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.

Lane	Signed by	Time
Information gathering `api.client.test` Receipted	Demo Reviewer [email protected] Signed with a key	Issued 2026-10-09 15:26:05 UTC Timestamped 2026-10-09 15:26:05 UTC by timestamp.digicert.com
Manifest SHA-256 `dc0b0155df6a04c04916c90b4c5f359046c9ea61d9f0af559d320229d3b5529b` Ed25519 key `3a1adcccf00897adc6bc4ab0d25bfb506ba1f6dc06a8c206180aa401e0aea88c`, registered 2026-10-09 15:26:04 UTC from their own session
Information gathering `app.client.test` Receipted	Demo Reviewer [email protected] Signed with a key	Issued 2026-10-09 15:26:05 UTC Timestamped 2026-10-09 15:26:05 UTC by timestamp.digicert.com
Manifest SHA-256 `51c1ec010b939c85aceefab3e30778b10852fded92492b5b089038231fa8a841` Ed25519 key `3a1adcccf00897adc6bc4ab0d25bfb506ba1f6dc06a8c206180aa401e0aea88c`, registered 2026-10-09 15:26:04 UTC from their own session
Configuration `app.client.test` Receipted	Demo Reviewer [email protected] Signed with a key	Issued 2026-10-09 15:26:06 UTC Timestamped 2026-10-09 15:26:06 UTC by timestamp.digicert.com
Manifest SHA-256 `6c6025a25ba6ec2d9e9fc4853141c4f4a1857df7bfb1d6d394a0408726a58cb1` Ed25519 key `3a1adcccf00897adc6bc4ab0d25bfb506ba1f6dc06a8c206180aa401e0aea88c`, registered 2026-10-09 15:26:04 UTC from their own session
Authorization `app.client.test` Receipted	Demo Reviewer [email protected] Signed with a key	Issued 2026-10-09 15:26:06 UTC Timestamped 2026-10-09 15:26:06 UTC by timestamp.digicert.com
Manifest SHA-256 `8ed282dde205101815ab8ba63a2e41d07fda63838736c1e37a869c9acc27840a` Ed25519 key `3a1adcccf00897adc6bc4ab0d25bfb506ba1f6dc06a8c206180aa401e0aea88c`, registered 2026-10-09 15:26:04 UTC from their own session
Session management `app.client.test` Receipted	Demo Reviewer [email protected] Signed with a key	Issued 2026-10-09 15:26:07 UTC Timestamped 2026-10-09 15:26:06 UTC by timestamp.digicert.com
Manifest SHA-256 `f37aa01e3b039ec06945c3393eccea320fed9a04e3d7d7b89205e60d107f49fb` Ed25519 key `3a1adcccf00897adc6bc4ab0d25bfb506ba1f6dc06a8c206180aa401e0aea88c`, registered 2026-10-09 15:26:04 UTC from their own session

1 opened lane has 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.

Time	By	Change
2026-10-09 15:25:28 UTC	recorded when the audit log was added	Person when the audit log was added: Demo Reviewer ([email protected])
2026-10-09 15:25:28 UTC	recorded when the audit log was added	Scope when the audit log was added: in scope api.client.test, app.client.test; out of scope none; rate limit 5 requests per second; identification header X-Pentest: client-engagement; user agent not set; opt-in modules none; crawl depth 3
2026-10-09 15:25:28 UTC	recorded when the audit log was added	Settings when the audit log was added: separation of duties off; required signatures on; evidence redaction on
2026-10-09 15:25:28 UTC	recorded when the audit log was added	Authorization when the audit log was added: by demo operator, under https://example.com/statement-of-work, recorded 2026-10-09T08:13:49.190759+00:00
2026-10-09 15:25:28 UTC	recorded when the audit log was added	Roles when the audit log was added: Demo Reviewer ([email protected]): reviewer
2026-10-09 15:26:04 UTC	the operator on the server	Reset the password of Demo Reviewer ([email protected]) on the server and signed them out; the operator knows it until they choose their own
2026-10-09 15:26:04 UTC	Demo Reviewer ([email protected])	Demo Reviewer ([email protected]) chose their own password

4 engagement entries and 3 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, tools/verify_report.py in the AttackLedger repository, and needs only Python 3 and its standard library.

Or 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). Copy verify_report.py and the tools/tsa-roots/ folder from the repository into one folder, keeping the folder name tsa-roots.

2. Run the verifier

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

For example, with the DigiCert root from the repository, 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.

Check	What it means
Report body hash	The report has not been edited since it was generated: its SHA-256 matches the recorded value.
Evidence chain	Every evidence entry links to the one before it, from the genesis value to the chain head. No entry was removed, reordered or changed. Each summary matches the hash the chain commits to; a summary deleted with the engagement's key is reported as unavailable and the chain is still checked.
Lane receipts	For every receipted lane, a manifest rebuilt from the report’s own items and evidence has the receipt’s hash, every item marked done has evidence, and every not-applicable item has a reason.
Receipt signatures	Each signed receipt verifies with the public key in the report, the key matches its fingerprint, and the signed text names this lane, this manifest and a chain head in the report. SKIP when no receipt is signed.
Signing key history	Each signing key’s entries in the key log hash correctly and link into the log in order, and the key was registered to the signer before the receipt was issued and not revoked before it. Shown only when the report has signed receipts.
Change history	The audit log entries in the report hash correctly and link into the log in order. For each receipt, the signer held the reviewer role on this engagement (or was an owner) and had the name in the receipt when it was issued; NOTE lines give the scope in force then. Shown only when the report carries the audit log.
Receipt timestamps	Each timestamp token covers this receipt’s manifest hash and signature, the authority’s signature verifies, and its certificate chain reaches a root you trust. SKIP when no receipt is timestamped.

Where the timestamp root comes from

tools/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.

Control	Framework	Receipted items	Status
DORA-ART8 Identification of ICT assets and risks	EU DORA (Regulation 2022/2554)	16 of 20 with evidence 4 not applicable	Resolved, partly not applicable
ISO-A.5.15 Access control	ISO/IEC 27001:2022 Annex A	4 of 18 with evidence	Partial
ISO-A.5.9 Inventory of information and other associated assets	ISO/IEC 27001:2022 Annex A	16 of 20 with evidence 4 not applicable	Resolved, partly not applicable
ISO-A.8.24 Use of cryptography	ISO/IEC 27001:2022 Annex A	1 of 12 with evidence	Partial
ISO-A.8.28 Secure coding	ISO/IEC 27001:2022 Annex A	0 of 88 with evidence	No evidence
ISO-A.8.5 Secure authentication	ISO/IEC 27001:2022 Annex A	8 of 38 with evidence 1 not applicable	Partial
ISO-A.8.9 Configuration management	ISO/IEC 27001:2022 Annex A	9 of 22 with evidence 2 not applicable	Partial
PCI-11.4.1 A penetration testing methodology is defined and followed	PCI DSS v4.0	16 of 20 with evidence 4 not applicable	Resolved, partly not applicable
PCI-11.4.3 External penetration testing is performed	PCI DSS v4.0	21 of 174 with evidence 3 not applicable	Partial
PCI-6.2.4 Software engineering techniques prevent or mitigate common software attacks	PCI DSS v4.0	12 of 130 with evidence 1 not applicable	Partial
PCI-6.4.1 Public-facing web applications are protected against attacks	PCI DSS v4.0	0 of 64 with evidence	No evidence

Item detail

api.client.test · Information gathering Receipted

Item	Result	Evidence
WSTG-INFO-01 Search engine discovery and reconnaissance for information leakage	Evidence recorded	#9 Note: lane 6 item 1 checked `59b7af71ae7a`
WSTG-INFO-02 Fingerprint the web server	Evidence recorded	#10 Note: lane 6 item 2 checked `9c26848dc0ee`
WSTG-INFO-03 Review webserver metafiles for information leakage	Evidence recorded	#11 Note: lane 6 item 3 checked `2f0e874c2c66`
WSTG-INFO-04 Enumerate applications on the webserver	Evidence recorded	#12 Note: lane 6 item 4 checked `2e384a0b0eac`
WSTG-INFO-05 Review webpage content for information leakage	Not applicable: not present on this host	none
WSTG-INFO-06 Identify application entry points	Evidence recorded	#13 Note: lane 6 item 6 checked `ad5f9a46d6a5`
WSTG-INFO-07 Map execution paths through the application	Evidence recorded	#14 Note: lane 6 item 7 checked `06f031d963fe`
WSTG-INFO-08 Fingerprint the web application framework	Evidence recorded	#15 Note: lane 6 item 8 checked `70f851c804a2`
WSTG-INFO-09 Fingerprint the web application	Evidence recorded	#16 Note: lane 6 item 9 checked `8f9a5b303d75`
WSTG-INFO-10 Map the application architecture	Not applicable: not present on this host	none

app.client.test · Information gathering Receipted

Item	Result	Evidence
WSTG-INFO-01 Search engine discovery and reconnaissance for information leakage	Evidence recorded	#1 Note: lane 5 item 1 checked `21ee57a2d39c`
WSTG-INFO-02 Fingerprint the web server	Evidence recorded	#2 Note: lane 5 item 2 checked `656b53fe693d`
WSTG-INFO-03 Review webserver metafiles for information leakage	Evidence recorded	#3 Note: lane 5 item 3 checked `5f537acc6d23`
WSTG-INFO-04 Enumerate applications on the webserver	Evidence recorded	#4 Note: lane 5 item 4 checked `e28a7f45efb5`
WSTG-INFO-05 Review webpage content for information leakage	Not applicable: not present on this host	none
WSTG-INFO-06 Identify application entry points	Evidence recorded	#5 Note: lane 5 item 6 checked `a8372bfca0b7`
WSTG-INFO-07 Map execution paths through the application	Evidence recorded	#6 Note: lane 5 item 7 checked `39ed9e992992`
WSTG-INFO-08 Fingerprint the web application framework	Evidence recorded	#7 Note: lane 5 item 8 checked `5fef2da8e444`
WSTG-INFO-09 Fingerprint the web application	Evidence recorded	#8 Note: lane 5 item 9 checked `906fec458c8e`
WSTG-INFO-10 Map the application architecture	Not applicable: not present on this host	none

app.client.test · Configuration Receipted

Item	Result	Evidence
WSTG-CONF-01 Test network infrastructure configuration	Evidence recorded	#17 Note: lane 7 item 1 checked `c4f4624fbd55`
WSTG-CONF-02 Test application platform configuration	Evidence recorded	#18 Note: lane 7 item 2 checked `ddc59ebc9fbb`
WSTG-CONF-03 Test file extension handling for sensitive information	Evidence recorded	#19 Note: lane 7 item 3 checked `dcd50c54a3b6`
WSTG-CONF-04 Review old backup and unreferenced files	Evidence recorded	#20 Note: lane 7 item 4 checked `f0714d00399c`
WSTG-CONF-05 Enumerate infrastructure and application admin interfaces	Not applicable: not present on this host	none
WSTG-CONF-06 Test HTTP methods	Evidence recorded	#21 Note: lane 7 item 6 checked `a20e6deae2ce`
WSTG-CONF-07 Test HTTP Strict Transport Security	Evidence recorded	#22 Note: lane 7 item 7 checked `741b9f30ce73`
WSTG-CONF-08 Test RIA cross-domain policy	Evidence recorded	#23 Note: lane 7 item 8 checked `4a560040dc2f`
WSTG-CONF-09 Test file permissions	Evidence recorded	#24 Note: lane 7 item 9 checked `fdbb9ccc1d79`
WSTG-CONF-10 Test for subdomain takeover	Not applicable: not present on this host	none
WSTG-CONF-11 Test cloud storage	Evidence recorded	#25 Note: lane 7 item 11 checked `c433371a14b5`

app.client.test · Authorization Receipted

Item	Result	Evidence
WSTG-ATHZ-01 Test for directory traversal and file inclusion	Evidence recorded	#26 Note: lane 8 item 1 checked `7eafbd2fb67f`
WSTG-ATHZ-02 Test for bypass of the authorization schema	Evidence recorded	#27 Note: lane 8 item 2 checked `0853f816af5e`
WSTG-ATHZ-03 Test for privilege escalation	Evidence recorded	#28 Note: lane 8 item 3 checked `d99f6940c239`
WSTG-ATHZ-04 Test for insecure direct object references	Evidence recorded	#29 Note: lane 8 item 4 checked `35faa3133235`

app.client.test · Session management Receipted

Item	Result	Evidence
WSTG-SESS-01 Test the session management schema	Evidence recorded	#30 Note: lane 9 item 1 checked `5475b2ca0eac`
WSTG-SESS-02 Test cookie attributes	Evidence recorded	#31 Note: lane 9 item 2 checked `4b042c7c6a62`
WSTG-SESS-03 Test for session fixation	Evidence recorded	#32 Note: lane 9 item 3 checked `3a15f3647e1e`
WSTG-SESS-04 Test for exposed session variables	Evidence recorded	#33 Note: lane 9 item 4 checked `5e02a08e362f`
WSTG-SESS-05 Test for cross-site request forgery	Not applicable: not present on this host	none
WSTG-SESS-06 Test logout functionality	Evidence recorded	#34 Note: lane 9 item 6 checked `f99f1db8c936`
WSTG-SESS-07 Test session timeout	Evidence recorded	#35 Note: lane 9 item 7 checked `4462deeead30`
WSTG-SESS-08 Test for session puzzling	Evidence recorded	#36 Note: lane 9 item 8 checked `7c90a7bd41f7`
WSTG-SESS-09 Test for session hijacking	Evidence recorded	#37 Note: lane 9 item 9 checked `0329386ab3ee`

app.client.test · Authentication In progress

Item	Result	Evidence
WSTG-ATHN-01 Test that credentials travel over an encrypted channel	Evidence recorded	#38 Note: lane 10 item 1 checked `caaca830b4a8`
WSTG-ATHN-02 Test for default credentials	Evidence recorded	#39 Note: lane 10 item 2 checked `3c0208c82e58`
WSTG-ATHN-03 Test for weak lockout mechanisms	Evidence recorded	#40 Note: lane 10 item 3 checked `f15b0d1e8d03`
WSTG-ATHN-04 Test for bypass of the authentication schema	Evidence recorded	#41 Note: lane 10 item 4 checked `ff30bab11c44`
WSTG-ATHN-05 Test for vulnerable remember-password functions	Not applicable: not present on this host	none
WSTG-ATHN-06 Test for browser cache weaknesses	Evidence recorded	#42 Note: lane 10 item 6 checked `c3ebef1242f8`
WSTG-ATHN-07 Test for weak password policy	Evidence recorded	#43 Note: lane 10 item 7 checked `257430959699`
WSTG-ATHN-08 Test for weak security question and answer	Open	none
WSTG-ATHN-09 Test for weak password change or reset functions	Open	none
WSTG-ATHN-10 Test for weaker authentication in alternative channels	Open	none

Integrity

Evidence entries: 43
Chain genesis: 0000000000000000000000000000000000000000000000000000000000000000
Chain head: bc4fcec42ad58bd4f654844a1460084d646efb5269875e120a8703443bbc9e04
Report body SHA-256: 6939c0a2553829d2d38f382e13b81fcf7e599c29e214393f4fc0b566dc4f4b0a

Every evidence entry commits to the hash of the entry before it, starting from the genesis value, so removing, reordering or editing any entry changes the chain head. The body hash covers everything in the report except this section. The full report is embedded in this page as JSON; see How to verify.