Use this guide for pipeline-focused CLI usage across platforms.
socketcli \
--reach \
--sarif-file results.sarif \
--sarif-scope full \
--sarif-grouping alert \
--sarif-reachability reachable \
--disable-blockingsocketcli \
--reach \
--sarif-file results.sarif \
--sarif-scope diff \
--sarif-reachability reachable \
--strict-blockingUse --config .socketcli.toml or --config .socketcli.json to keep pipeline commands small.
Precedence order:
CLI flags > environment variables > config file > built-in defaults
Example:
[socketcli]
reach = true
sarif_scope = "full"
sarif_grouping = "alert"
sarif_reachability = "reachable"
sarif_file = "results.sarif"Equivalent JSON:
{
"socketcli": {
"reach": true,
"sarif_scope": "full",
"sarif_grouping": "alert",
"sarif_reachability": "reachable",
"sarif_file": "results.sarif"
}
}- name: Run Socket CLI
run: socketcli --config .socketcli.toml --target-path .
env:
SOCKET_SECURITY_API_TOKEN: ${{ secrets.SOCKET_SECURITY_API_TOKEN }}steps:
- label: "Socket scan"
command: "socketcli --config .socketcli.toml --target-path ."
env:
SOCKET_SECURITY_API_TOKEN: "${SOCKET_SECURITY_API_TOKEN}"Notes for using --base-commit-sha (see the
merge-base note in the CLI reference)
when your steps are emitted by a
dynamic pipeline
generator rather than a static YAML file:
-
Compute the merge base at generation time, not step time. The generator runs with a full checkout; step agents may have shallow or fresh clones where
git merge-basefails or needs an extra fetch. Resolve it once in the generator and bake it into the emitted step'senv. Diff against the PR's target branch, which isn't always the default branch (see Buildkite's environment variables):TARGET="${BUILDKITE_PULL_REQUEST_BASE_BRANCH:-$BUILDKITE_PIPELINE_DEFAULT_BRANCH}" BASE_SHA=$(git merge-base "origin/${TARGET}" HEAD)
-
Emit the backfill step conditionally from the generator. The generator is the natural place for the "does a baseline scan exist?" check (
GET /orgs/{org}/full-scans?repo=<repo>&commit_hash=$BASE_SHA&per_page=1): only emit the baseline-scan step when it returns nothing. The emitted pipeline then shows in the UI whether a backfill will run. -
Keep the backfill inside one command step. The checkout-base → scan → checkout-PR sequence must not be split across steps — steps can land on different agents with different checkouts. Prefer
git worktreeover mutating the step's checkout:git worktree add /tmp/socket-base "$BASE_SHA"thensocketcli --target-path /tmp/socket-base --branch "$TARGET" --disable-blocking. -
Soft-fail infra errors, not findings. A missing baseline (or any API error) exits with code 3 (
--exit-code-on-api-errorto change it); real findings exit 1.soft_fail: [{exit_status: 3}]on the PR scan step keeps infra errors from blocking merges while security findings still do. -
"Cancel intermediate builds" on the default branch is the main source of baseline gaps. Canceled builds never scan their commit, so merge-base lookups for PRs based on those commits fail. The conditional backfill step above is the remedy; there is no per-step exemption from build cancellation in Buildkite. If you need strict scan-once semantics for concurrent backfills of the same merge base, serialize the backfill step with a concurrency group keyed on the merge-base SHA.
socket_scan:
script:
- socketcli --config .socketcli.toml --target-path .
variables:
SOCKET_SECURITY_API_TOKEN: $SOCKET_SECURITY_API_TOKENpipelines:
default:
- step:
script:
- socketcli --config .socketcli.toml --target-path .Prebuilt examples in this repo:
../workflows/github-actions.yml../workflows/buildkite.yml../workflows/gitlab-ci.yml../workflows/bitbucket-pipelines.yml
--strict-blockingenables strict diff behavior (new + unchanged) for blocking evaluation and diff-based output selection.--sarif-scope fullrequires--reach.--sarif-grouping alertcurrently applies to--sarif-scope full.- Diff-based SARIF can validly be empty when there are no matching net-new alerts.
- Keep API tokens in secret stores (
SOCKET_SECURITY_API_TOKEN), not in config files.