PR/MR runs compare the new scan against the repository's head scan. That comparison first uses the diff-scans endpoints, which require an organization token with these scopes in addition to whatever the scan itself needs:

• diff-scans:create
• diff-scans:list
• full-scans:list

If the token is missing them the scan still succeeds, so this is easy to miss. The only signal is a warning, after which the CLI falls back to the older streaming comparison:

Diff scan comparison failed with APIAccessDenied(Insufficient permissions), falling back to the streaming scan comparison

Grant the scopes to use the diff-scans path. It polls with short, bounded requests rather than holding one connection open while the backend computes, which is what lets large comparisons survive network idle timeouts — notably Azure NAT gateways, which reap idle connections after four minutes and surface as an intermittent ConnectionResetError.

The two paths can take noticeably different amounts of time on the same repository, because cached diff-scan responses always embed per-package license details while the streaming comparison requests a lean payload. On a large dependency tree, compare the Diff scan comparison ready in ... timing against the Diff Report Gathered in ... total before assuming either path is at fault.

• In diff scope, --strict-blocking uses a stricter alert set (new + unchanged) for blocking checks and diff-based output selection.
• --sarif-scope full requires --reach.
• In --sarif-scope full with --sarif-file, SARIF JSON is written to file and stdout JSON is suppressed.
• --sarif-grouping alert currently applies to --sarif-scope full.

Differences in result counts can be valid, even when filtering appears similar.

Common reasons:

• diff vs full data source:
  • --sarif-scope diff is based on diff alerts (typically net-new in the compared scan context).
  • --sarif-scope full is based on full reachability facts data.
• Consolidation differences:
  • Dashboard and API/CLI can apply different consolidation/grouping rules.
  • --sarif-grouping alert and --sarif-grouping instance intentionally produce different row counts.
• Policy vs dataset:
  • --strict-blocking only affects diff-scope behavior and does not make diff output equivalent to full dashboard data.
• Reachability data availability:
  • If reachability analysis partially fails and falls back to precomputed reachability, counts can shift.

Recommended comparison path:

1. Use full-scope SARIF for parity-oriented comparisons.
2. Keep grouping fixed (alert for dashboard-style rollups, instance for detailed exports).
3. Compare reachability filters with the same mode and grouping across runs.

Use --save-submitted-files-list to inspect exactly what was sent for scanning.

socketcli --save-submitted-files-list submitted_files.json

Output includes:

• timestamp
• total file count
• total size
• complete submitted file list

Use --save-manifest-tar to export discovered manifest files as .tar.gz.

socketcli --save-manifest-tar manifest_files.tar.gz

Combined example:

socketcli --save-submitted-files-list files.json --save-manifest-tar backup.tar.gz

For octopus merges (3+ parents), Git can report incomplete changed-file sets because default diff compares against the first parent.

If needed, force full scan behavior with:

• --ignore-commit-files

If report is not visible in GitLab Security Dashboard:

• verify dependency_scanning artifact is configured in .gitlab-ci.yml
• verify job completed and artifact uploaded
• verify report file schema is valid

If vulnerabilities array is empty:

• this can be expected when no actionable security issues are present in the result scope
• confirm expected scope/flags and compare with Socket dashboard data