Repository navigation
Conversation
The docs named the scopes `full-scans` and `socket-basics`, which are not scope names; the API checks `full-scans:create` and `socket-basics:read`. They also left out that Socket Tier 1 needs `full-scans:create`, and that a missing scope never fails the run. - Add an API token scopes section to the parameters reference: a least-privilege scope table, then every Socket API call by step (dashboard configuration, result upload, Socket Tier 1) with the scope it checks, when it is called and how a denial shows up in the log - Note that on an Enterprise organization a key without `socket-basics:read` also loses organization discovery, so `SOCKET_ORG` must be set for the upload - Note which token variables each step reads, and that the Socket npm CLI prefers its own variables over the one Tier 1 passes - Correct the scope names in the README, the GitHub Action guide and the Docker guide, and link them to the new section
PR SummaryLow Risk Overview The main addition is a new Reviewed by Cursor Bugbot for commit 66eba35. Configure here. |
|
bugbot run |
There was a problem hiding this comment.
✅ Bugbot reviewed your changes and found no new issues!
Comment @cursor review or bugbot run to trigger another review on this PR
Reviewed by Cursor Bugbot for commit 66eba35. Configure here.
Summary
Socket Basics needs two API token scopes:
full-scans:createandsocket-basics:read. The docs named themfull-scansandsocket-basics, which aren't valid scope names, and said nothing about Socket Tier 1 or about what a missing scope does. A missing scope never fails the run. It only logs, so a misconfigured token goes unnoticed.Changes
docs/parameters.md:full-scans:create. The engine-download endpoint,coana-cli/artifacts, works with any valid token.README.md,docs/github-action.mdanddocs/local-install-docker.md. The README keeps a short version that links to the new subsection.socket-basics:readmakes the dashboard-config step fail. That step also throws away the org it discovered, so results don't upload unlessSOCKET_ORGis set.SOCKET_SECURITY_API_KEY,SOCKET_SECURITY_API_TOKENandINPUT_SOCKET_SECURITY_API_KEY. A key set only asSOCKET_API_KEYskips it.SOCKET_SECURITY_API_KEY, but that CLI prefersSOCKET_CLI_API_TOKEN,SOCKET_CLI_API_KEYorSOCKET_SECURITY_API_TOKENwhen one is set. If several are set to different tokens, Tier 1 can use a different token from the rest of the run.full-scans:createfor that.full-scans:createbut notsocket-basics:read.socketcli, the docs link to its permissions guide rather than repeating it. Improve documentation for requisite API token permissions socket-python-cli#353 adds that guide, so merge this after #353, or at the same time.Questions this answers
security-policy:reador thetriage:*scopes? No. It makes no triage or security-policy calls, and neither doessocketcli. So those three scopes on the CI/CD key guide aren't there for either Python tool. The npm CLI'ssocket ciusessecurity-policy:read.socket scan reach, neither of which calls the diff-scans endpoints.docs/parameters.md, with a short version in the README). A docs-site page would be a separate change.Related PRs
#api-token-scopessection, so merge this PR before that one.Testing
Docs only.
python3 scripts/check_release_docs.py --checkpasses. Each call was traced in the source: the directsocketdevSDK calls, and the published Socket npm CLI that runssocket scan reachfor Tier 1. Options passed throughsocket_additional_paramscan make more calls, and the docs say those aren't covered.Fixes: CE-463
Refs: CE-384