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
* feat: add --strict-blocking flag to fail on any existing security violations
Introduces a new --strict-blocking flag that causes builds to fail on ANY
security policy violations with blocking severity, not just new ones. This
enables enforcement of a zero-tolerance policy on security issues.
Key features:
- Works in diff mode only (logs warning in API mode)
- Only fails on error-level alerts (not warnings)
- --disable-blocking takes precedence when both flags are set
- Enhanced console output distinguishes NEW vs EXISTING violations
- Comprehensive test coverage for all scenarios
Implementation details:
- Added unchanged_alerts and removed_alerts fields to Diff class
- Created get_unchanged_alerts() method to extract alerts from unchanged packages
- Updated report_pass() to check both new and unchanged alerts when enabled
- Added validation warnings for conflicting flags and API mode limitations
Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
* chore: update uv.lock with version 2.2.63
Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
* docs: add --strict-blocking flag documentation to README
Added comprehensive documentation for the new --strict-blocking feature:
- Added flag to Advanced Configuration parameters table
- Created dedicated "Strict Blocking Mode" section with:
- Behavior comparison (standard vs strict)
- Usage examples for different CI/CD platforms
- Output examples showing NEW vs EXISTING violations
- Common use cases and implementation strategies
- Important notes about limitations and flag priority
- Flag combination examples
- Migration strategy guidance
- Links to GitLab CI example files
The documentation clearly explains:
- Zero-tolerance security policy enforcement
- Diff mode requirement
- Error-level filtering (not warnings)
- --disable-blocking precedence
- First scan behavior
Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
* chore: bump version to 2.3.1 for --strict-blocking feature
Bumped version from 2.2.63 to 2.3.1 following semantic versioning
(minor version bump for new feature).
This version number avoids conflict with the mucha-dev-gitlab-security-output
branch which uses 2.3.0 for the GitLab Security Dashboard feature.
Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
* version sync
* Bumping version
---------
Co-authored-by: Jonathan Mucha <jonathan@mucha.local>
Co-authored-by: Claude Sonnet 4.5 <noreply@anthropic.com>
Co-authored-by: Douglas Coburn <douglas@dactbc.com>
| --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. |
196
197
| --enable-diff | False | False | Enable diff mode even when using --integration api (forces diff mode without SCM integration) |
197
198
| --scm | False | api | Source control management type |
198
199
| --timeout | False | | Timeout in seconds for API requests |
- `alert_types` (array, optional): Only send specific alert types
329
330
- `reachability_alerts_only` (boolean, default: false): Only send reachable vulnerabilities when using `--reach`
330
331
332
+
## Strict Blocking Mode
333
+
334
+
The `--strict-blocking` flag enforces a zero-tolerance security policy by failing builds when **ANY** security violations with blocking severity exist, not just new ones introduced in the current changes.
335
+
336
+
### Standard vs Strict Blocking Behavior
337
+
338
+
**Standard Behavior (Default)**:
339
+
- ✅ Passes if no NEW violations are introduced
340
+
- ❌ Fails only on NEW violations from your changes
0 commit comments