Audit Context Building
Trail of BitsOfficialPublished by Trail of Bits
- Skill
- Research and analysis
- Security
- CC-BY-SA-4.0
- Medium risk
AutoGineer summary
Written by AutoGineer from the skill’s own files, not by the author
Audit Context Building is a preparatory workflow designed to establish a comprehensive understanding of an unfamiliar codebase. By mapping out function-level assumptions, guarantees, and cross-function dependencies, it creates a structured dossier that serves as the foundation for subsequent vulnerability hunting. It explicitly separates the context-gathering phase from the bug-finding phase to ensure that security assessments are based on a complete, documented understanding of the system's logic rather than premature assumptions.
What it does
- Analyzes function-level assumptions, guarantees, and dependencies.
- Generates a central dossier and individual function records.
- Identifies critical gaps where code relies on unverified assumptions.
- Documents open questions and areas of ambiguity within the codebase.
- Maps cross-function rules and reachability paths.
- Provides a standardized format for auditing diverse targets like C, Solidity, or web services.
When to use it
- At the start of a security audit, threat model, or architecture review.
- When working with an unfamiliar codebase.
- When previous audit attempts failed due to a lack of system-wide understanding.
- Before performing any vulnerability-hunting or exploit-development tasks.
Advantages
- Prevents premature or inaccurate vulnerability reporting.
- Highlights 'nothing found' assumptions that are prime targets for security research.
- Creates a shared, objective map of the system for the audit team.
- Ensures that complex code paths are traced thoroughly rather than guessed.
Usage examples
- “Run the audit context building workflow on the src/auth directory.”
- The agent will analyze the functions in the specified directory, generating a dossier and individual function reports detailing assumptions and dependencies.
- “Analyze the single function verify_signature in crypto.c using the context builder.”
- The agent will perform a focused analysis of that specific function, returning a structured record of its internal logic and external requirements.
Install
Download the skill as a ZIP:
https://autogineer.com/agent-skills/trailofbits/audit-context-building/downloadUnzip it into the cross-client skills folder of your project:
mkdir -p .agents/skills && unzip audit-context-building.zip -d .agents/skills
Documentation by Trail of Bits
Audit Context Building
Build understanding, not verdicts. This runs before anyone hunts for bugs, and feeds that work.
When to Use
At the start of an audit, a threat model, or an architecture review, when the code is unfamiliar. Also when an earlier pass produced findings nobody could judge, because no one had mapped out how the system fits together.
When NOT to Use
Do not name vulnerabilities, suggest fixes, write proofs-of-concept, or rate severity. Those belong to the hunting phase, which runs next and with the whole picture in hand. When the code counts on something and nothing checks it, record that plainly and move on — whether it matters is decided later.
Not worth the tokens on code you already understand.
Do not analyze in this context
The analysis is long, and this context needs to survive to use it. Dispatch it:
A codebase, or more than one function — run
/audit-context-building:audit-context <path>. It orients, analyzes each function in its own subagent, and writesaudit-context/DOSSIER.mdplus one file per function underaudit-context/functions/. Only compact records return here.A single function — dispatch the
audit-context-building:function-analyzeragent at it. It writes its prose to disk and returns a record.
Then work from what comes back: the index, the unenforced assumptions, the open questions. Read a function's file when you need its detail.
The workflow is what enforces this, not this text: a subagent bound to a return schema cannot return prose. Treat this section as routing, and route.
What comes back, and how to read it
Each record lists what must always be true (with the line that shows it), what the function takes on faith (with whatever establishes it), which functions it calls and what it needs from each, and anything still unclear. The dossier adds the rules that span several functions, who can reach what, and where the complicated parts cluster.
Two things matter more than the rest:
Assumptions marked
nothing found. The code counts on something being true and nothing anywhere makes it true. This is the most useful thing to hand the hunting phase.The open questions. An honest list of what is still unclear beats a confident answer that turns out to be wrong. Carry them forward instead of closing them out.
Where two records disagree, both are quoted rather than quietly reconciled. That is a fact about the code, not a flaw in the analysis.
The format
ANALYSIS_FORMAT.md defines it, and FUNCTION_MICRO_ANALYSIS_EXAMPLE.md works through examples in C and Solidity. Read them when extending this plugin or deciding whether a record can be trusted.
The format is the same whatever the target. What changes is what fills each slot, and what counts as a call you cannot see inside. DOMAIN_NOTES.md maps that across smart contracts, C and C++, decompiled firmware, and web services — read it when the target is not plain source code.
The rule that matters most: follow the calls. Whether a function is correct usually depends on something
another function does, and you cannot see that from the caller alone. A limit looks enforced because the
value came back from a function whose name suggests it was checked. So read the function being called, follow
every path through it rather than only the one that succeeds, and say what makes each assumption true. When
nothing does, use those words: nothing found. Every claim cites a line, or becomes an open question.
Files
- ATTRIBUTION.mdAdded by AutoGineer960 B
- LICENSELicence file added by AutoGineer19.7 KiB
- SKILL.md3.9 KiB
- agents/openai.yaml253 B
- assets/trail-of-bits-mark.svg3.0 KiB
- resources/ANALYSIS_FORMAT.md2.6 KiB
- resources/DOMAIN_NOTES.md4.9 KiB
- resources/FUNCTION_MICRO_ANALYSIS_EXAMPLE.md8.8 KiB
resources/DOMAIN_NOTES.md
Domain Notes
The format never changes. Whatever the target, you are always asking the same four questions up front — what are the pieces, how does the outside world get in, who is on the other side, and what data survives between calls — and then, per function, what must be true, what it takes on faith, and what it calls.
What changes is the answers, and what counts as a call you cannot see inside. That is what this file maps.
| ways in | who's on the other side | data that sticks around | calls you can't see inside | |
|---|---|---|---|---|
| Smart contracts | external / public function | caller, owner, relayer, oracle, other protocols | storage slots | an address whose code isn't in the project |
| C / C++ source | exported function, parser, syscall or IPC handler | remote peer, local user, other threads | globals, statics, long-lived heap | a linked library shipped without source |
| Decompiled / firmware | task entry, interrupt handler, protocol handler | radio peer, LAN host, serial console | fixed addresses, NVRAM, DMA regions | a symbol the decompiler never resolved |
| Web services (Go, Rust, Python) | route handler, RPC method, queue consumer | logged-in user, anonymous caller, internal service | database rows, cache entries, sessions | a third-party API |
Contracts
The original target of this plugin, and the one where "external call" carries the most weight. A call to an address whose code is not in scope is the black-box case: record the value and calldata sent, and the outcomes not excluded — revert, a hostile return value, and re-entry into the caller before its own state writes land. Whether the write lands before or after the call is usually the whole question in "why here".
Implicit inputs are larger than they look: the caller identity, the block timestamp, the gas left, and anything read from another contract. Under effects, storage writes and emitted events are separate lines, because indexers depend on the events and solvency depends on the writes.
Watch for unchecked blocks and assembly. Both suspend guarantees the surrounding code is written as though
it still has, which is exactly the shape the continuity rule exists to catch — a caller relies on a checked
subtraction that a callee performs unchecked.
C and C++ source
Bounds, lifetimes, and integer width carry most of the invariants. An out-parameter is the classic continuity trap: the caller checks the return code and uses the out-parameter, and one path through the callee returns success without writing it, or writes it without bounding it.
Record who owns each pointer and until when. free on one path and not another, a borrow that outlives the
lock that protected it, and a length in int compared against a size_t are all structural facts, not
findings. Note which calls are behind #ifdef — a path that only exists in one build configuration is still
a path, and orientation should say which configuration was read.
Decompiled binaries and firmware
Three things differ, and they all land in orientation.
Function boundaries are themselves a finding. Before anything can be ranked, the functions have to be
recovered, and the recovery is fallible. Say which entry points were identified, how, and what was left
unattributed. FUN_80104a2c is a name that tells you nothing — the rule against inferring behavior from a
name is not a caution here, it is the default condition.
Go top-down from task entry points. Starting at RTOS task entries, interrupt handlers, and protocol handlers and working downward beats exploring outward from whatever looked interesting. The entrypoint list is the work queue.
Most callees are black boxes, and that is the normal case rather than an exception. A call to an address
with no recovered body — a ROM thunk, a syscall, a library the decompiler did not resolve — gets the same
treatment as an unknown external contract: what is passed, what is assumed, what is not excluded. A bound
that is never established in the visible listing is an assumption with establishedBy: "nothing found", and
that is a complete and useful answer, not a failure to finish.
Keep a coverage record alongside the dossier: which tasks and handlers have been analyzed and which have not. Without it there is no way to tell a clean subsystem from an unread one.
Services
Logic and authorization carry more weight than memory safety. The trust boundary is usually a middleware chain, so the continuity rule points at the framework: a handler is safe because something upstream authenticated the request, and that something is a decorator, a route registration, or a config file rather than a call in the handler's body. Record where the check actually lives, and whether every route registered on that path gets it.
Concurrency is persistent state. Two handlers that read-modify-write the same row without a transaction are coupled even though neither calls the other; that belongs in shared state and invariant couplings.
Requirements and compatibility
Works with: Claude Code, Claude apps, OpenAI Codex, GitHub Copilot, Cursor, Gemini CLI, Kiro, OpenCode, Goose, Amp, Roo Code, JetBrains Junie, Factory Droid, Devin (ex-Windsurf), Mistral Vibe, OpenHands, Letta
“Works with” means the tool reads the open Agent Skills format; a skill written for one tool may use features others lack.
Needs: Declares allowed tools
Security
What our scanner noticed· Medium risk
- Zero-width Unicode characters
A static scan is not a guarantee. Skills are third-party content: review a skill before you let an agent use it.
Attribution and licence
- Published by
- Trail of Bits
- Publisher
- Trail of Bits (Official)
- Source
- trailofbits/skills · plugins/audit-context-building/skills/audit-context-building · commit e4dd0bb
- Licence
- Creative Commons Attribution-ShareAlike 4.0 International (redistribution allowed)
- LICENSE (added by AutoGineer from LICENSE)
- ATTRIBUTION.md (written by AutoGineer)
- Synced
AutoGineer is not affiliated with or endorsed by Trail of Bits or Trail of Bits.
Download ZIP
The ZIP holds the skill’s files, its licence files and an ATTRIBUTION.md. Download audit-context-building.zip