socketcli --scm gitlab --pr-number 123 --strict-blocking
Example Output:
Security issues detected by Socket Security:
 - NEW blocking issues: 2
 - EXISTING blocking issues: 5 (causing failure due to --strict-blocking)
Why?
Current Limitation
The Socket CLI currently only fails builds when new security violations are introduced. Existing violations in the codebase are ignored, which means:
- Teams can accumulate technical security debt over time
- Protected branches may contain unresolved vulnerabilities
- No enforcement mechanism for gradual security improvement
- Difficult to implement zero-tolerance security policies
Use Cases Enabled by This Feature
1. Zero-Tolerance Security Policies
Organizations with strict security requirements can enforce that NO violations exist at any time. This is especially important for:
- Financial services and healthcare applications
- Government and defense contractors
- PCI-DSS, HIPAA, or SOC2 compliant systems
- Production/main branch protection
2. Gradual Security Improvement
Teams can use --strict-blocking alongside standard scans to:
- Block new violations immediately (standard behavior)
- Monitor existing violations with warnings (strict scan with allow_failure: true)
- Gradually resolve legacy issues
- Eventually enforce strict blocking (set allow_failure: false)
3. Protected Branch Enforcement
Require all security violations to be resolved before merging to critical branches:
rules:
 - if: $CI_COMMIT_BRANCH == "main"
 # Only main branch requires strict blocking
4. Scheduled Security Audits
Run periodic scans that fail if any violations accumulate over time, ensuring continuous security posture monitoring.
Benefits
- Prevents Security Debt: Stops violations from accumulating in the codebase
- Clear Visibility: Console output explicitly shows NEW vs EXISTING issues
- Flexible Adoption: Can be phased in gradually with allow_failure configuration
- Backwards Compatible: Existing workflows continue to work unchanged
- Well-Documented: Comprehensive README section and GitLab CI examples included
Implementation Highlights
- Added unchanged_alerts and removed_alerts fields to Diff class
- Created get_unchanged_alerts() method to extract alerts from unchanged packages
- Updated report_pass() exit code logic to check both new and unchanged alerts when enabled
- Enhanced output_console_comments() to distinguish violation sources in console output
- Added validation warnings for conflicting flags and API mode limitations
- Comprehensive test coverage: 15+ new unit tests across 3 test files
Related Documentation
- Full usage guide in README (new "Strict Blocking Mode" section)
- GitLab CI examples available (can be added in separate PR if needed)
- Migration strategy guidance included
Public Changelog
New Feature: --strict-blocking Flag
Added a new --strict-blocking flag that enforces zero-tolerance security policies by failing builds when ANY security violations with blocking severity exist, not just new ones.
What's New:
- Fail builds on both NEW and EXISTING blocking violations
- Enhanced console output showing "NEW blocking issues" vs "EXISTING blocking issues"
- Works in diff mode with full GitLab, GitHub, Bitbucket, and Azure DevOps integration
- Only affects error-level alerts (blocking severity), not warnings

Usage Example:
socketcli --scm gitlab --pr-number 123 --strict-blocking

Use Cases:
- Enforce zero-tolerance security policies for critical branches
- Prevent security debt accumulation over time
- Gradually improve security posture with phased adoption
- Meet compliance requirements (PCI-DSS, HIPAA, SOC2)

Important Notes:
- Only works in diff mode (requires baseline scan for comparison)
- --disable-blocking flag takes precedence if both are set
- See README for complete documentation and migration strategies