Review code you don't own (audits, forensics, litigation)¶
Auditors, security reviewers, forensic examiners, and litigation-support engineers face a harder setup than a team analyzing its own code: you didn't write it, you often can't build it, and you may not even get the project or build files. Understand is a good fit here because it analyzes source statically — but the setup deserves its own playbook.
This page collects the how-tos that matter when the codebase is someone else's.
Get a usable project without a build¶
For most languages, no build information is needed — add sources by directory and let Understand find what it can, rather than reconstructing the original project structure.
C/C++ is the exception: the default Strict parser wants the include paths and macros your build
would supply. When the delivery has no compile_commands.json and no working build, you have two
levers:
- Give Strict a best-effort configuration — point it at whatever include roots ship with the delivery and define the few macros that matter (see Fix parse errors).
- Switch to Fuzzy parsing, which tolerates missing headers and incomplete configuration — the fastest way to a first look. See Strict vs Fuzzy.
Fuzzy and modern C++
The Fuzzy parser's language model is C++03-era. It won't fail on newer code, but C++11-and-later
constructs (auto type deduction, lambdas, constexpr, and everything since) are not modeled,
so cross-references in modern C++ will be incomplete. For a C++11-or-later codebase, a
best-effort Strict configuration usually beats Fuzzy.
Accuracy vs. speed of setup
Fuzzy trades some cross-reference precision for resilience. For a defensible review, note where analysis was incomplete (parse errors, unresolved references) rather than assuming completeness.
Tame the parse errors¶
A foreign codebase will throw parse errors. You don't need zero — you need enough resolved to answer your question. Work the highest-impact ones (missing include roots, a few key macros) with Fix parse errors, and watch Parse Accuracy on the Home dashboard so you know how much to trust a given result.
Handle foreign and broken paths¶
Client machines, delivered archives, and protective-order review rooms rarely match the paths baked into a project. A teammate can't open my project / paths broke covers Named Roots and portable projects so the database resolves against wherever the source actually sits.
Work with large, slow deliveries¶
Forensic and audit deliveries can be huge. If analysis or the UI bogs down, see Performance on a large codebase — and consider splitting a delivery into the self-contained subsets you actually need to examine.
Keep it defensible¶
In litigation especially, what the tool does can be challenged. Understand reads source statically; it does not compile, execute, or simulate the code — see Is Understand a compiler? for the plain answer to give a reviewer or opposing counsel.
Where to next¶
- Create an accurate C/C++ project (Strict vs Fuzzy).
- Understanding & reverse-engineering legacy code — once the project analyzes, the exploration workflow.
- Check code for security vulnerabilities (CWE, CERT) — for a security audit, run the CWE and CERT checks against the delivery.
- Working across mixed-language codebases — third-party deliveries often mix languages; analyze them in one project.