Skip to main content

Every part of the report does a job.

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

Walk through the report See it in services

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

An 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 we spent, right on the cover. It is the single most important number for weighting a finding, so we lead with it instead of burying it in an appendix.

    Status QuoMost firms omit effort entirely, so engagements look bigger than they were.

  2. 02

    Executive summary

    p. 4

    Severity and difficulty, scored separately.

    Each finding gets two scores: severity, which is what could happen, and difficulty, which is how hard the bug is to reach. An easy medium can outrank a hard critical, and the matrix shows you which is which.

    Status QuoA single severity number collapses both dimensions into one ambiguous score.

  3. 03

    Codebase maturity evaluation

    p. 7

    Maturity scored on six engineering dimensions.

    We grade testing, documentation, access controls, supply-chain hygiene, error handling, and configuration, each on its own. The grades tell you where to invest beyond the individual bugs.

    Status QuoPen-test reports stop at the findings list, with no maturity grade and no engineering-practice rubric.

  4. 04

    Per-finding section

    p. 18

    A step-by-step exploit scenario for every finding.

    Every finding includes a concrete adversary walkthrough: what an attacker does, in order, to reach impact. That lets your team build the right mental model before they patch.

    Status QuoGeneric descriptions leave engineers guessing whether a bug is real or theoretical.

  5. 05

    Per-finding section

    p. 19

    Short-term and long-term fixes, together.

    Short-term is the patch you ship this sprint. Long-term is the structural change, a Semgrep rule, an invariant, a process, that keeps the next variant of the same bug class from shipping.

    Status QuoOne-line "fix the comparison operator" recommendations let the next variant ship.

  6. 06

    Appendix: artifacts

    p. 51

    Runnable artifacts your CI can execute.

    We ship custom Semgrep and CodeQL rules tuned to the patterns we found, fuzzing harnesses, LLM and Claude-skill harnesses, and exploit proofs of concept. All of it runs on day one.

    Status QuoMost reports come without code, so 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 your patches land, we re-test and append the verification to the same document. One file tells you what is now fixed, what still is not, and what risk you accepted.

    Status QuoVerifying fixes is sold as a separate engagement, or skipped entirely.

  8. 08

    Publication

    p. 64

    Optional public release.

    If you choose to publish, your report joins our public catalog of security reviews, with the methodology and artifacts open for anyone to read. Your findings become reference material the whole industry learns from.

    Status QuoOther 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

Largest engagements

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