Cargo (Rust)
Full Application Reachability setup guide for Rust projects.
This guide covers Full Application Reachability (previously Tier 1) via the
--reachflag. For an overview of all reachability types, see the Reachability Analysis overview.
Prerequisites
Install Socket CLI:
npm install -g socket
socket loginOr set API key:
export SOCKET_SECURITY_API_TOKEN=sktsec_<your_key>Note:
socket scan createrequires an org slug. Runsocket loginto set a default, or pass--org <your-org-slug>on every command.
Runtime Requirements for Full Application Reachability
- Rust 1.74 or newer: the toolchain your project selects (such as from
rust-toolchain.toml, or the rustup default), able to resolve its crates and run its build scripts and procedural macros - The
rust-srccomponent on that toolchain. With rustup, the analysis installs it if missing (or runrustup component add rust-srcbeforehand on restricted networks). For toolchains not managed by rustup (Homebrew, distro packages), make sure the toolchain shipsrust-src. Otherwise the scan fails with "the toolchain resolved no sysroot ... 'rust-src' is a prerequisite".
Step 1: Ensure Cargo.lock Exists
Cargo projects use static manifest files — no SBOM generation needed. Ensure Cargo.lock is committed to source control:
cargo generate-lockfile
git add Cargo.lockSocket reads these manifest files directly:
Cargo.tomlCargo.lock(if missing, the analysis generates one in the workspace root)
Step 2: Run Baseline Scan
Scan without reachability to establish baseline CVE count:
socket scan create .Note the total CVE count.
Step 3: Run Reachability Scan
Execute scan with Full Application Reachability enabled:
socket scan create --reach .Socket constructs a cross-dependency call graph from source code to determine which CVEs are exploitable. The project does not need to be compiled first, but the analysis runs your build scripts and procedural macros, so the project must be buildable.
Note: Rust is statically typed with strong ownership semantics, making reachability analysis fast and accurate. 8 GB RAM is typically sufficient. Very large Cargo workspaces (e.g., Servo, 250+ crates) may take 20+ minutes for backend dependency processing — increase
--reach-analysis-timeoutaccordingly.
Local-Only Alternative
To run reachability analysis locally without uploading results:
socket scan reachResults are saved to .socket.facts.json.
Note: Delete
.socket.facts.jsonbefore runningsocket scan createwithout--reach. Otherwise it is uploaded as an SBOM carrying stale reachability results.
Performance Tuning
For large Cargo workspaces, adjust these flags as needed:
socket scan create --reach \
--reach-analysis-timeout 20m \
--reach-analysis-memory-limit 32GB \
--reach-concurrency 4 \
.| Flag | Default | Description |
|---|---|---|
--reach-analysis-timeout | 10m | Per-run analysis timeout; specify with an s, m, or h unit (e.g. 90s, 10m, 1h) |
--reach-analysis-memory-limit | 8GB | Per-run memory limit; specify with an MB or GB unit (e.g. 512MB, 8GB) |
--reach-concurrency | 1 | Maximum concurrent analysis runs (one per project or workspace); give each run at least --reach-analysis-memory-limit of memory |
Step 4: Compare Results
In Socket Dashboard, view the reachability scan and filter by reachability status.
The CLI outputs a Noise% column directly. You can also calculate manually:
Noise% = ((Unreachable + NoSup + NoReach) / Total Vulns) × 100
The CLI outputs a summary table per ecosystem:
Project │ Vulns │ Reach │ Unreach │ NoSup │ NoReach │ Skipped │ Error │ Noise% │ Time
Result Categories
| Column | Meaning |
|---|---|
| Reach | Call chain exists from app code to vulnerable function |
| Unreach | No exploitable call chain; safe to ignore |
| NoSup | Socket hasn't classified the vulnerable functions for this CVE yet |
| NoReach | Reachability analysis not possible for this vulnerability |
| Skipped | Filtered out via --exclude-paths or other options |
| Error | Analysis error; check logs or contact support |
| Noise% | Percentage of vulns filtered as non-reachable |
In the Dashboard, additional statuses appear: Potentially Reachable (precomputed reachability indirect chain), Pending Precomputation (precomputed reachability processing), Not Determinable, and Unknown.
Step 5: Triage Reachable CVEs
Review CVEs marked as "Reachable" in Dashboard. For each:
- Check severity and CVSS score
- Evaluate upgrade path
- Prioritize remediation
Step 6: Override Unreachable CVEs (Optional)
For unreachable CVEs with low business impact, click Override in Dashboard to suppress from future scans.
Updated about 23 hours ago