22
33Use this guide for pipeline-focused CLI usage across platforms.
44
5+ The shell commands in the recommended patterns are CI-provider neutral. Buildkite
6+ pipeline equivalents and provider-specific considerations are called out alongside
7+ the relevant guidance below.
8+
59## Recommended patterns
610
711### Dashboard-style reachable SARIF
@@ -27,6 +31,27 @@ socketcli \
2731 --strict-blocking
2832```
2933
34+ ### Buildkite: retain SARIF as a build artifact
35+
36+ Either recommended pattern can run directly in a Buildkite command step. When the
37+ scan writes SARIF, add
38+ [ ` artifact_paths ` ] ( https://buildkite.com/docs/pipelines/configure/artifacts#upload-artifacts-with-a-command-step )
39+ so developers can download the report from the build after the command finishes:
40+
41+ ``` yaml
42+ steps :
43+ - label : " :socket: Socket reachable diff"
44+ command : |
45+ socketcli \
46+ --reach \
47+ --sarif-file results.sarif \
48+ --sarif-scope diff \
49+ --sarif-reachability reachable \
50+ --strict-blocking
51+ artifact_paths :
52+ - " results.sarif"
53+ ` ` `
54+
3055## Config file usage in CI
3156
3257Use ` --config .socketcli.toml` or `--config .socketcli.json` to keep pipeline commands small.
@@ -60,6 +85,9 @@ Equivalent JSON:
6085}
6186` ` `
6287
88+ The Buildkite examples below use the same checked-in `.socketcli.toml` file; no
89+ Buildkite-specific config-file format is required.
90+
6391# # Platform examples
6492
6593# ## GitHub Actions
@@ -73,14 +101,33 @@ Equivalent JSON:
73101
74102# ## Buildkite
75103
104+ This example assumes a GitHub-hosted repository. Change
105+ ` SOCKET_SCM_INTEGRATION` to `gitlab` for a GitLab-hosted repository, or `api`
106+ when provider association is not wanted. The doubled dollar signs defer
107+ Buildkite variable expansion until the command runs on an agent.
108+
76109` ` ` yaml
110+ env:
111+ SOCKET_SCM_INTEGRATION: "github"
112+
77113steps:
78114 - label: "Socket scan"
79- command : " socketcli --config .socketcli.toml --target-path ."
80- env :
81- SOCKET_SECURITY_API_TOKEN : " ${SOCKET_SECURITY_API_TOKEN}"
115+ command: |
116+ socketcli \
117+ --config .socketcli.toml \
118+ --target-path . \
119+ --integration "$${SOCKET_SCM_INTEGRATION:-api}" \
120+ --pr-number "$${BUILDKITE_PULL_REQUEST:-0}"
121+ secrets:
122+ - SOCKET_SECURITY_API_TOKEN
82123` ` `
83124
125+ The `secrets` block expects a
126+ [Buildkite secret](https://buildkite.com/docs/pipelines/security/secrets/buildkite-secrets)
127+ named `SOCKET_SECURITY_API_TOKEN`. If your organization uses an external secrets
128+ plugin or an agent hook instead, remove that block and inject the same environment
129+ variable through your existing mechanism. Do not store the token in pipeline YAML.
130+
84131# ### Merge-base baselines in Buildkite (dynamic pipelines)
85132
86133Notes for using `--base-commit-sha` (see the
@@ -139,6 +186,18 @@ socket_scan:
139186 SOCKET_SECURITY_API_TOKEN: $SOCKET_SECURITY_API_TOKEN
140187` ` `
141188
189+ # ## Azure Pipelines
190+
191+ ` ` ` yaml
192+ - script: |
193+ socketcli \
194+ --integration azure \
195+ --enable-diff \
196+ --target-path "$(Build.SourcesDirectory)"
197+ env:
198+ SOCKET_SECURITY_API_TOKEN: $(SOCKET_SECURITY_API_TOKEN)
199+ ` ` `
200+
142201# ## Bitbucket Pipelines
143202
144203` ` ` yaml
@@ -149,6 +208,44 @@ pipelines:
149208 - socketcli --config .socketcli.toml --target-path .
150209` ` `
151210
211+ # # Pull request and Dashboard association
212+
213+ The CLI sends the resolved pull request number with each full scan and attaches
214+ the pull request URL to diff scans so the Socket Dashboard can associate the
215+ report with its originating change. If `--pr-number` is supplied, it wins;
216+ passing `--pr-number 0` explicitly disables automatic association.
217+
218+ Without an explicit value, the CLI recognizes :
219+
220+ - GitHub Actions : ` PR_NUMBER` , then the PR number in `GITHUB_REF`.
221+ - GitLab CI : ` CI_MERGE_REQUEST_IID` .
222+ - Azure Pipelines : ` SYSTEM_PULLREQUEST_PULLREQUESTNUMBER` for GitHub-hosted
223+ repositories, otherwise `SYSTEM_PULLREQUEST_PULLREQUESTID` for Azure Repos.
224+
225+ # ## Buildkite PR context
226+
227+ Buildkite is SCM-provider neutral, so the CLI does not infer a provider or consume
228+ its PR variable automatically. Pass Buildkite's
229+ [`BUILDKITE_PULL_REQUEST`](https://buildkite.com/docs/pipelines/configure/environment-variables#BUILDKITE_PULL_REQUEST)
230+ value to
231+ ` --pr-number` and identify the repository host with `--integration`, as shown in
232+ the Buildkite platform example above. Buildkite sets `BUILDKITE_PULL_REQUEST` to
233+ ` false` outside PR builds; the CLI treats that value as no PR.
234+
235+ Use `--integration github` for GitHub-hosted repositories and `--integration gitlab`
236+ for GitLab-hosted ones. In both cases the CLI reads the repository slug and host from
237+ [`BUILDKITE_REPO`](https://buildkite.com/docs/pipelines/configure/environment-variables#BUILDKITE_REPO)
238+ to build the pull request or merge request link, so github.com, GitLab.com, and
239+ self-hosted installations all work without extra configuration. Setting
240+ ` CI_PROJECT_URL` still overrides the derived GitLab project URL. Keep `--scm api`
241+ unless you also intend to configure an existing GitHub or GitLab comment adapter and
242+ its provider token.
243+
244+ ` --scm github` and `--scm gitlab` also imply the matching scan integration for
245+ Dashboard metadata unless `--integration` was explicitly supplied. PR comments
246+ remain limited to the existing GitHub and GitLab SCM adapters; Azure receives
247+ console output and Dashboard association but does not post a PR comment.
248+
152249# # Workflow templates
153250
154251Prebuilt examples in this repo :
@@ -165,3 +262,11 @@ Prebuilt examples in this repo:
165262- ` --sarif-grouping alert` currently applies to `--sarif-scope full`.
166263- Diff-based SARIF can validly be empty when there are no matching net-new alerts.
167264- Keep API tokens in secret stores (`SOCKET_SECURITY_API_TOKEN`), not in config files.
265+ - In Buildkite pipeline YAML, follow its
266+ [runtime interpolation](https://buildkite.com/docs/pipelines/configure/environment-variables#runtime-variable-interpolation)
267+ guidance and use `$$` for variables that must expand when the command runs rather
268+ than when the pipeline is uploaded.
269+ - Security findings with `props.firstPatchedVersionIdentifier` show that value in
270+ the console table, including native Buildkite job logs, and in GitHub/GitLab
271+ security comments when that SCM adapter is configured. Findings without a known
272+ patched release leave the console cell blank and omit the comment field.
0 commit comments