Blockchain Attestation

The Trust Problem in Pentest Reports

A pentest report is a claim: "On this date, we tested this target, and these were the findings." But how does a third party - an auditor, a customer, a regulator - verify that claim? Traditional reports are PDF files that can be modified after the fact. A company could run a pentest, receive a report full of critical findings, fix nothing, and then edit the PDF to show a clean result before handing it to an auditor.

TurboPentest's attestation system solves this problem by creating a tamper-evident, publicly verifiable record that a specific pentest produced specific results at a specific time. Today this is delivered with SHA-256 content hashing and a public verification link: a verifier checks the report and attestation hashes against the verification page. The report itself always stays private; only cryptographic hashes - never report contents - are ever involved. Merkle-tree batching and anchoring the Merkle root on the Base blockchain are the designed next steps in this system (covered below); on-chain publishing is not yet live, and per-leaf Merkle proofs are not yet exposed to verifiers, so treat both as the roadmap rather than a currently-running mechanism.

SHA-256 Content Hashing

The foundation of blockchain attestation is cryptographic hashing. TurboPentest uses SHA-256 (Secure Hash Algorithm, 256-bit) to create unique fingerprints of the pentest results.

SHA-256 takes any input - a full findings dataset, a single sentence, or a terabyte file - and produces a fixed-length 256-bit (32-byte) output called a digest or hash. This hash has critical properties:

• Deterministic - The same input always produces the same hash
• Irreversible - You cannot reconstruct the input from the hash
• Collision-resistant - It is computationally infeasible to find two different inputs that produce the same hash
• Avalanche effect - Changing a single bit of the input produces a completely different hash

When a pentest completes, TurboPentest creates an attestation record with three hashes:

1. Report hash - The SHA-256 hash of the pentest's findings data. If anyone changes even one byte of the findings - a modified severity rating, an edited description, a removed finding - the hash will be entirely different.
2. Target hash - The SHA-256 hash of the normalized target domain, so the attestation can reference the target without revealing it.
3. Attestation hash - A SHA-256 hash over the full attestation: the hashed pentest ID, target hash, credit tier, agent hours, agent count, duration, number of tools run, finding counts by severity, risk score, report hash, and completion timestamp.

The attestation hash is the value designed to be anchored on-chain (via the Merkle root below). Because it commits to the report hash and all the engagement metadata, any post-hoc modification of the results is detectable through hash verification - independently of whether the batch has been anchored on-chain yet.

Merkle Tree Anchoring

Writing every individual hash to a blockchain would be expensive and slow. TurboPentest's design uses Merkle trees to batch multiple attestations so that a single hash (the Merkle root) can represent the whole batch in one on-chain transaction.

How a Merkle Tree Works

A Merkle tree is a binary tree of hashes. Here is how TurboPentest constructs one:

1. Leaf nodes - Each unanchored attestation hash (along with credit ledger event hashes, covered in Module 5) becomes a leaf in the tree. Leaves are themselves SHA-256 hashed.
2. Pairwise hashing - Adjacent nodes are hashed together in pairs (sorted for deterministic ordering) to produce a parent node.
3. Recursive construction - This process repeats up the tree until there is a single root hash - the Merkle root.
4. Root anchoring - Only the Merkle root is destined for the blockchain; the design writes just this single root, never the individual leaves.

The Merkle root is a single hash that cryptographically represents every attestation in the batch. If any one attestation in the batch changes, its leaf hash changes, which cascades up the tree and changes the Merkle root.

Merkle Proofs

To verify that a specific attestation is included in a Merkle root, you do not need access to everything in the batch. You only need a Merkle proof: the sibling hashes along the path from your leaf to the root.

For a tree with 8 leaves, the Merkle proof for any single leaf requires only 3 sibling hashes (log2(8) = 3). For a tree with 1,000 leaves, you need only 10 sibling hashes. This logarithmic efficiency makes inclusion verification fast and lightweight. TurboPentest's Merkle library implements both proof generation and proof verification - but this is the engine for the roadmap: per-leaf proofs are not yet persisted or returned by the public verification API, so verifiers cannot obtain and check a Merkle proof today. Today's tamper-evidence is the SHA-256 report/attestation hash checked against the verification page.

Base L2: The Intended Attestation Chain

TurboPentest is designed to anchor Merkle roots on Base, an Ethereum Layer 2 (L2) rollup built on the OP Stack (chain ID 8453). On-chain publishing is not yet live (the anchoring contract is not yet deployed), so the following describes the design and roadmap for how anchoring will work. Base was selected because it balances security, cost, and speed:

Why Layer 2 Instead of Ethereum Mainnet?

Ethereum mainnet provides maximum security but at significant cost. A simple data storage transaction on mainnet can cost $5-50+ depending on gas prices. For a platform that produces thousands of attestations, this is not economically viable.

Layer 2 rollups inherit Ethereum's security guarantees while dramatically reducing costs. Base transactions cost fractions of a cent, which is what makes per-batch attestation economically feasible even at high volume once anchoring goes live.

Why Base Specifically?

• Ethereum security inheritance - Base posts transaction data to Ethereum mainnet, inheriting its security guarantees
• OP Stack foundation - Built on Optimism's open-source, battle-tested rollup technology
• Low cost - Transaction fees typically under $0.01, enabling frequent attestation batches
• Coinbase backing - Operated by Coinbase with strong infrastructure reliability
• EVM compatibility - Standard Ethereum tooling, wallets, and block explorers work directly

The Anchoring Process (Designed)

The anchoring job is designed to run on a daily batch schedule. When on-chain publishing is live, each run will:

1. Collection - All attestation hashes and credit ledger event hashes that have not yet been anchored are collected
2. Tree construction - A Merkle tree is built from all collected hashes
3. Root extraction - The Merkle root is extracted from the tree
4. On-chain transaction - A transaction is submitted to Base containing the Merkle root and the batch's event count
5. Anchor record - The transaction hash, block number, chain ID, root hash, and batch period are recorded, and every attestation and ledger event in the batch is linked to the anchor

Once a batch is anchored, the Base transaction will be publicly visible on any Base block explorer, so anyone can look up the transaction and see the anchored Merkle root. Until anchoring goes live, verification relies on the SHA-256 report/attestation hash checked against the public verification page, which is available today - the Merkle proof is part of the same not-yet-live roadmap.

What Attestation Proves

Blockchain attestation proves three things:

1. Existence - The attestation (and the results it commits to) existed at the time the Merkle root was anchored on-chain
2. Integrity - The attested results have not changed since attestation (hash verification)
3. Temporal ordering - The blockchain timestamp provides a trustworthy record of when the attestation was anchored

It does not prove that the report's findings are accurate or that the pentest was conducted competently. It proves that these specific results existed in this exact form at this specific time - which is precisely what auditors and compliance frameworks need.

The Verification Pipeline

End-to-end verification works as follows:

1. An auditor receives a pentest report and a verification link (covered in Module 6)
2. The verification page shows the attestation details: tier, agent hours, duration, tools run, finding counts by severity, and risk score
3. The page also shows the cryptographic proof: the attestation hash, target hash, and report hash
4. When the batch has been anchored, the page shows the on-chain anchor: the Merkle root, the Base transaction hash, the chain ID, and the block number
5. The auditor can look up the transaction on a Base block explorer and confirm the anchored Merkle root matches what the verification page displays

The on-chain anchor is independent of TurboPentest: once a Merkle root is anchored on Base, no one - including TurboPentest - can alter it. That on-chain step is the roadmap, not yet live; today the tamper-evidence is provided by the SHA-256 report/attestation hash, which anyone can recompute from the report and check against the public verification page (and the public verify API). The Merkle proof is part of the same roadmap and is not yet exposed to verifiers. The downloadable attestation letter for each pentest records the report hash, and - once anchoring is live - the transaction hash and block number, so the reference survives alongside the report.