Cargo (Rust)

Full Application Reachability setup guide for Rust projects.

This guide covers Full Application Reachability (previously Tier 1) via the --reach flag. For an overview of all reachability types, see the Reachability Analysis overview.

Prerequisites

Install Socket CLI:

npm install -g socket
socket login

Or set API key:

export SOCKET_SECURITY_API_TOKEN=sktsec_<your_key>

Note: socket scan create requires an org slug. Run socket login to 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-src component on that toolchain. With rustup, the analysis installs it if missing (or run rustup component add rust-src beforehand on restricted networks). For toolchains not managed by rustup (Homebrew, distro packages), make sure the toolchain ships rust-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.lock

Socket reads these manifest files directly:

  • Cargo.toml
  • Cargo.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-timeout accordingly.

Local-Only Alternative

To run reachability analysis locally without uploading results:

socket scan reach

Results are saved to .socket.facts.json.

Note: Delete .socket.facts.json before running socket scan create without --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 \
  .
FlagDefaultDescription
--reach-analysis-timeout10mPer-run analysis timeout; specify with an s, m, or h unit (e.g. 90s, 10m, 1h)
--reach-analysis-memory-limit8GBPer-run memory limit; specify with an MB or GB unit (e.g. 512MB, 8GB)
--reach-concurrency1Maximum 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

ColumnMeaning
ReachCall chain exists from app code to vulnerable function
UnreachNo exploitable call chain; safe to ignore
NoSupSocket hasn't classified the vulnerable functions for this CVE yet
NoReachReachability analysis not possible for this vulnerability
SkippedFiltered out via --exclude-paths or other options
ErrorAnalysis 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.


Did this page help you?