Trail of Bits

Anatomy of a Report

Every part of the report does a job.

Open the cover and pull each section apart — eight parts, each one in the report because an engineer reading it has a decision to make or an action to take.

Walk through the report

Trail of Bits · Security Review · Sample Protocol v1.3 64 pp · PDF

Trail of Bits

Security Assessment of Sample Protocol v1.3

Engagement period
Mar 3 – May 12, 2026
Engineers
4
Level of effort
10 person-weeks
Methodology
Hybrid review
Cover p. 1 / 64
skip · p. 4

Executive summary

12 findings across protocol layer, deployment configuration, and access controls. Two high-severity issues require attention before mainnet release.

Severity ↓ / Difficulty → Low Med High
High●●
Medium●●●
Low●●●●●●
Executive summary p. 4 / 64
skip · p. 7

Codebase maturity evaluation

  • DocumentationWeak
  • TestingModerate
  • Access controlsSatisfactory
  • Supply-chain hygieneStrong
  • Error handlingWeak
  • ConfigurationModerate
Codebase maturity p. 7 / 64
skip · p. 18

Finding · TOB-2026-007

Insufficient validation of cross-chain message origin

Severity · High Difficulty · Low

Exploit scenario

An attacker controlling any L2 relayer drafts a message that the L1 verifier accepts as canonical, draining the bridge escrow over three blocks…

Short-term

Add origin assertion in verifyMessage() against the trusted bridge address.

Long-term

Introduce a typed-message envelope with origin in its hash preimage; Semgrep rule attached.

Findings · TOB-2026-007 pp. 18–19 / 64
skip · p. 51

Appendix A · Artifacts shipped with this report

  • Semgrep4 rules
  • CodeQL2 queries
  • Fuzz harness3 targets
  • Claude skill1 skill
  • Exploit PoCs7 scripts
  • CI snippetsGH Actions
Appendix A · Artifacts p. 51 / 64
skip · p. 59

Appendix B · Fix review

  • TOB-2026-007Fixed · v1.3.2
  • TOB-2026-009Fixed · v1.3.2
  • TOB-2026-011Open · risk accepted
Appendix B · Fix review p. 59 / 64
skip · p. 64

trailofbits/publications

github.com ↗

Back cover p. 64 / 64

Illustrative excerpt from a typical 64-page report — every annotated section appears in every report we publish.

  1. 01

    Cover page

    p. 1

    Level of effort, on the cover.

    Every report we publish lists the person-weeks invested — on the cover, not buried in an appendix. It's the single most important number for calibrating how much weight a finding should carry.

    Status Quo · Most firms omit effort entirely so engagements look bigger than they were.

  2. 02

    Executive summary

    p. 4

    Severity × difficulty matrix, not a severity column.

    Each finding gets two axes: severity (what could happen) and difficulty (how hard to reach). A medium-severity bug that's easy to hit often matters more than a critical one behind three trust boundaries.

    Status Quo · Single-number severity collapses both dimensions into one ambiguous score.

  3. 03

    Codebase maturity evaluation

    p. 7

    Maturity scored on six engineering dimensions.

    We evaluate testing, documentation, access controls, supply-chain hygiene, error handling, and configuration practice — and grade each one. Tells you where to invest beyond the bugs we found.

    Status Quo · Pen-test reports stop at the findings list. No maturity grade, no engineering-practice rubric.

  4. 04

    Per-finding section

    p. 18

    Exploit scenario, not just description.

    Every finding includes a step-by-step adversary walkthrough — what an attacker does, in order, to reach impact. Your team builds the right mental model before they patch.

    Status Quo · Generic descriptions leave engineers guessing whether a bug is real or theoretical.

  5. 05

    Per-finding section

    p. 19

    Short-term AND long-term fixes.

    Short-term: the specific patch you ship this sprint. Long-term: the SDLC change — a Semgrep rule, an invariant, a process — that prevents the next variant of the same class.

    Status Quo · One-line 'fix the comparison operator' recommendations let the next variant ship.

  6. 06

    Appendix: artifacts

    p. 51

    Drop-in artifacts your CI will run.

    Custom Semgrep / CodeQL rules tuned to the patterns we found, fuzzing harnesses, LLM and Claude-skill harnesses, exploit PoCs. Every artifact ships with the report — runnable from day one.

    Status Quo · Most reports come without code. You hire us for the bug list and rebuild the tooling yourself.

  7. 07

    Appendix: fix review

    p. 59

    Fix-review re-test in the same report.

    When the patches land, we re-test and append the verification — same document, same version. The report tells you not just what was wrong, but what's now fixed and what isn't.

    Status Quo · Verifying fixes is sold as a separate engagement, or skipped entirely.

  8. 08

    Publication

    p. 64

    Optional public release on github.com/trailofbits/publications.

    If you choose to publish, your report joins our open catalog of 200+ public reviews. The methodology is documented, the artifacts are open, and every finding becomes industry reference material.

    Status Quo · Other firms compete on secrecy. We compete on shared knowledge.

Side by side

Deliverable Trail of Bits Status Quo
Level of effort on the cover
Severity × difficulty matrix
Codebase maturity grade
Exploit scenario per finding Sometimes
Short- and long-term recommendations
Custom Semgrep / CodeQL / fuzz harness artifacts
LLM and Claude-skill harnesses
Fix-review re-test in the same report Sometimes
Optional public release of the report

See it in practice

View All

By discipline

View All

Hire Trail of Bits

Pick a domain to start the conversation. Every engagement ships the parts you just walked through.

AI/ML Security

Learn More

Blockchain

Learn More

Cryptography

Learn More

Application Security

Learn More

Security Engineering

Learn More

Research & Development

Learn More