NuGet (.NET)

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

• .NET 6+
• With --dynamic-sbom-inference: the .NET SDK your project builds with, able to restore its packages

Step 1: Ensure Lockfile Exists

For best accuracy, commit packages.lock.json files. Enable lock file generation in your project:

<!-- In your .csproj file, add: -->
<PropertyGroup>
  <RestorePackagesWithLockFile>true</RestorePackagesWithLockFile>
</PropertyGroup>

dotnet restore
git add '**/packages.lock.json'

Socket reads these manifest files directly:

• packages.lock.json (recommended)
• *.csproj
• packages.config
• *.nuspec

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 to determine which CVEs are exploitable. The project does not need to be compiled first.

Note: C#/.NET is statically typed, making reachability analysis faster and less resource-intensive than dynamic languages. 8 GB RAM is typically sufficient. Projects with non-standard .csproj structures may encounter XML parsing errors during reachability — ensure .csproj files are well-formed.

Recommended: --dynamic-sbom-inference

Add --dynamic-sbom-inference to have dotnet resolve the dependency graph for each build. It covers every solution under the scan target, plus any project that no solution builds, and reachability is analyzed and reported per build:

socket scan create --reach --dynamic-sbom-inference .

This runs dotnet restore and writes a Socket facts file (a name ending in .socket.facts.json, such as App.csproj.socket.facts.json) for each solution or standalone project. These files stay in your working tree after the scan; commit them, or ignore them with a pattern such as *.socket.facts.json.

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 NuGet 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.