Mucha dev fail on any block

[jonathanStrange0]

Add --strict-blocking flag to fail on any existing security violations

Introduces a new --strict-blocking flag that causes builds to fail when ANY security policy violations with blocking severity exist, not just new ones introduced in the current changes. This enables organizations to enforce zero-tolerance security policies across their entire codebase.

Key Features:

• ✅ Fails on both NEW and EXISTING blocking violations (not just new ones)
• 🔒 Only affects error-level alerts (blocking severity), not warnings
• 🎯 Works in diff mode with full SCM integration
• 📊 Enhanced console output distinguishes NEW vs EXISTING violations
• ⚙️ --disable-blocking takes precedence when both flags are set

Usage:

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

[github-actions]

🚀 Preview package published!

Install with:

pip install --index-url https://test.pypi.org/simple/ --extra-index-url https://pypi.org/simple socketsecurity==2.2.66.dev1

Docker image: socketdev/cli:pr-149