Bundler (Ruby)

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.

Step 1: Ensure Gemfile.lock Exists

Full Application Reachability requires Gemfile.lock. With only a Gemfile, the analysis finds no projects and exits without an error. Ensure Gemfile.lock is committed to source control:

bundle install
git add Gemfile.lock

Socket reads these manifest files directly:

• Gemfile.lock (fully supported)
• Gemfile (partial support)
• .gemspec (partial support)

Note: If you don't have a Gemfile.lock, run bundle lock to generate one without installing gems.

Note: Ruby reachability analysis does not currently run on Linux arm64 hosts (for example AWS Graviton, or Docker on Apple Silicon). Run it on macOS or Linux x64.

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 built first. If gems aren't installed locally, the analysis downloads them itself and prints "Dependencies are not preinstalled. This can result in CVEs with unknown reachability if you use private dependencies". Run bundle install first so private gems resolve.

Note: Ruby is dynamically typed, so reachability analysis is more resource-intensive than statically typed languages. Ensure at least 16 GB RAM available. Very large Ruby monorepos (e.g., Rails) may encounter analysis errors in the Coana analyzer — increase --reach-analysis-timeout or contact Socket support.

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 Bundler projects, adjust these flags as needed:

socket scan create --reach \
  --reach-analysis-timeout 20m \
  --reach-analysis-memory-limit 32GB \
  --reach-concurrency 4 \
  .

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

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.