Go Modules

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

Go at or above the go version in your go.mod. With the default GOTOOLCHAIN=auto, Go downloads the required toolchain automatically.

Step 1: Ensure go.sum Exists

Go Modules projects use static manifest files — no SBOM generation needed. Ensure go.sum is committed to source control:

go mod tidy
git add go.mod go.sum

Socket reads these manifest files directly:

go.mod
go.sum

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.

Note: Go is statically typed, making reachability analysis faster and less resource-intensive than dynamic languages. 8 GB RAM is typically sufficient.

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 Go projects, 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.