You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The write-access gate had no escape hatch, and its GitLab behavior when project
membership cannot be read -- honor the command with a warning -- was the one
deliberate weakness in it. Both are now a choice:
enforce (default) require write access; honor with a warning where the
provider cannot report it
strict reject in that case instead
off perform no check
enforce closes the hole wherever the provider can answer without breaking a
pipeline whose token cannot read membership, which is why it is the default.
strict closes it everywhere and will fail those pipelines. off restores the prior
behavior for anyone who needs comment-driven ignores from unverified authors.
Threaded through the adapter constructors as a keyword argument with a default, so
existing call sites keep working. With off the predicate is never handed to
check_for_socket_comments at all, so nothing is filtered and no rejection is
logged, rather than a gate that silently approves everything.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|`--disable-blocking`| False | False | Non-blocking CI mode: the CLI always exits **0**, even when blocking alerts are present (including with `--strict-blocking`). Also exits 0 on uncaught runtime errors and Socket API failures, so the job is treated as successful while findings and errors are still logged. Takes precedence over `--strict-blocking`. |
434
434
|`--disable-ignore`| False | False | Disable support for`@SocketSecurity ignore` commandsin PR comments. When set, alerts cannot be suppressed via comments and ignore instructions are hidden from comment output. See [Who can ignore an alert](#who-can-ignore-an-alert). |
435
+
|`--ignore-authorization`| False | enforce | Who may suppress alerts with `@SocketSecurity ignore`. `enforce` requires write access and honors the command with a warning when the provider cannot report it;`strict` rejects it in that case;`off` honors any commenter. See [Who can ignore an alert](#who-can-ignore-an-alert). |
435
436
|`--strict-blocking`| False | False | Fail on ANY security policy violations (blocking severity), not just new ones. Only works in diff mode. See [Strict Blocking Mode](#strict-blocking-mode) for details. |
436
437
|`--enable-diff`| False | False | Enable diff mode even when using `--integration api` (forces diff mode without SCM integration) |
437
438
|`--scm`| False | api | Source control management type|
@@ -704,10 +705,21 @@ reported. `--disable-ignore` turns the feature off entirely.
704
705
| GitLab | Project membership, read once per run when an ignore command is present. Developer (30) or above is honored. | The command is honored and a warning is logged. |
705
706
706
707
GitLab notes carry no permission field, so the check needs a `GITLAB_TOKEN` that
707
-
can read`GET /projects/:id/members/all`. A `CI_JOB_TOKEN` generally cannot, and
708
-
in that case the CLI logs a warning and still honors the command rather than
709
-
breaking a pipeline that was already relying on it. Use a personal or group access
710
-
token with API read access to get enforcement.
708
+
can read`GET /projects/:id/members/all`. A `CI_JOB_TOKEN` generally cannot.
709
+
710
+
`--ignore-authorization` decides what happens when access cannot be determined:
711
+
712
+
| Value | Verified write access | Access cannot be determined |
0 commit comments