Only if you pass the lockfile explicitly. The cargo-audit README warns that when Cargo.lock is missing, the tool runs cargo update to create one, which can execute project code. For an untrusted project, supply the lockfile with the file option and run the command from a directory outside the project.
Why a scanner can run code
It seems odd that an audit tool could execute anything. The reason is Cargo itself. Resolving dependencies can involve reading manifests and build configuration from the project directory. Project level config can alter how Cargo behaves. If the scanner invokes Cargo inside an untrusted checkout, you are trusting that checkout.
Safe pattern
- Obtain a lockfile you trust the origin of. If the project has one, copy only that file.
- Create an empty working directory away from the project.
- Run the audit pointing at the copied file:
cargo audit --file /path/to/copy/Cargo.lock
- Read the findings. Do not follow links that automatically run code.
- Do this inside a disposable environment if the lockfile is the only artifact you have.
What to avoid
| Risky | Safer |
|---|---|
| Cloning an unknown repo and running the audit in it | Copy the lockfile out and audit it elsewhere |
| Letting the tool generate a lockfile in the project | Supply one explicitly |
| Running on a machine with cloud credentials loaded | Use a throwaway container or virtual machine |
Related habits for untrusted Rust code
Building a crate runs its build script, and procedural macros run at compile time, so even opening a build can execute code from dependencies. For hostile or unknown code, build only in an isolated environment with no secrets and limited network. The Cargo reference describes build scripts as programs Cargo compiles and runs just before building the package.
Also remember that a missing lockfile means resolution is not pinned, so the result of a generated lock can differ by day. A lockfile supplied by the project is at least a stable statement of what its author used.
When this comes up
Reviewing a vendor library, evaluating an open source project before adoption, triaging a bug report with an attached repository, or running scanners across many repositories in bulk. The bulk case is where a mistake scales, so bake the safe pattern into the automation rather than relying on each person.
Limits
An audit tells you about known advisories. It does not tell you whether the code is hostile. Reading a clean report is not a safety clearance for running the project.
Try it yourself
Click through it at your own pace, or open it full screen. Look at what an inventory can tell you from the component list alone.
Quick check
Does the file option remove all risk?
It removes the lockfile generation step. You should still treat the project as untrusted and avoid building it outside isolation.
Why does a missing lockfile matter?
The tool then generates one with an update command, and that is where project code may run.
Safeguard SBOM and dependency scanning can inventory dependencies from a lockfile, and a free scan is available at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
