René's URL Explorer Experiment

Title: Mucha dev fail on any block by jonathanStrange0 · Pull Request #149 · SocketDev/socket-python-cli · GitHub

Open Graph Title: Mucha dev fail on any block by jonathanStrange0 · Pull Request #149 · SocketDev/socket-python-cli

X Title: Mucha dev fail on any block by jonathanStrange0 · Pull Request #149 · SocketDev/socket-python-cli

Description: 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

Open Graph Description: 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 ...

X Description: 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 ...

Opengraph URL: https://github.com/SocketDev/socket-python-cli/pull/149

X: @github

direct link

Domain: github.com

Links:

Viewport: width=device-width