Should a failing security scan block the build: how do you choose blocking criteria, remediation SLAs by severity, and an auditable exception process?

# WRONG: block on every HIGH or above -- too noisy
- run: mvn dependency-check:check -DfailBuildOnCVSS=7
# Result: every build fails, team bypasses the gate
# Developer trust in the gate is destroyed

# CORRECT: block on Critical + reachable, or on CISA KEV list
- run: mvn dependency-check:check -DfailBuildOnCVSS=9
# Critical findings block. Pre-existing Mediums become tracked tickets.

# A sensible blocking policy:
# Block if: Critical (CVSS >= 9.0) AND reachable
# Block if: On CISA KEV list (regardless of CVSS)
# Block if: Newly introduced HIGH (not pre-existing)
# Track (don't block): pre-existing Mediums and Lows
# Track (don't block): non-reachable findings

package com.bank.security;

import java.math.BigDecimal;

public class VulnerabilityPolicy {

    public enum Decision { BLOCK, TRACK, ACCEPT }

    public Decision evaluate(BigDecimal cvssScore, boolean reachable, boolean onKevList,
                             boolean newlyIntroduced) {
        // Block: on KEV list regardless of CVSS
        if (onKevList) return Decision.BLOCK;

        // Block: Critical AND reachable
        if (cvssScore.compareTo(new BigDecimal("9.0")) >= 0 && reachable) return Decision.BLOCK;

        // Block: newly introduced HIGH
        if (cvssScore.compareTo(new BigDecimal("7.0")) >= 0 && newlyIntroduced) return Decision.BLOCK;

        // Track: everything else gets an SLA
        return Decision.TRACK;
    }
}

 Gate vs. SLA -- two different jobs:

 Gate:  Stops NEW critical issues from entering production
        (blocks the build on this commit)

 SLA:   Drives DOWN the existing backlog over time
        (tracked tickets with deadlines)

 Metric: mean-time-to-remediate (MTTR) measures program health

# .snyk policy file -- exception with governance metadata
ignore:
  'SNYK-JAVA-COMFABORXML-6053542':
    - '*':
        reason: >-
          No patch available. Vulnerable path is not reachable in our
          configuration (confirmed by security team review SR-2024-042).
        expires: 2024-06-30T00:00:00.000Z
        created: 2024-03-15T00:00:00.000Z

 A good exception MUST record:

 1. Who requested it          (developer name)
 2. Who approved it            (security owner -- NOT the developer)
 3. Business justification     (why we cannot fix now)
 4. Compensating control       (what mitigates the risk)
 5. Expiry date                (when the gate re-blocks automatically)

 When the exception expires:
   - The gate fails again
   - Forces a fresh review
   - Either the fix is applied or a new exception is justified
   - This is what makes it auditable

package com.bank.security;

import java.time.LocalDate;

public class SecurityException {
    private final String vulnerabilityId;
    private final String requestedBy;
    private final String approvedBy;
    private final String justification;
    private final String compensatingControl;
    private final LocalDate expiryDate;

    public SecurityException(String vulnerabilityId, String requestedBy,
                             String approvedBy, String justification,
                             String compensatingControl, LocalDate expiryDate) {
        this.vulnerabilityId = vulnerabilityId;
        this.requestedBy = requestedBy;
        this.approvedBy = approvedBy;
        this.justification = justification;
        this.compensatingControl = compensatingControl;
        this.expiryDate = expiryDate;
    }

    public boolean isExpired() {
        return LocalDate.now().isAfter(expiryDate);
    }

    // When expired, the gate re-blocks automatically
}

# WRONG: blocking on everything -- developers lose trust
- run: trivy image --exit-code 1 --severity LOW,MEDIUM,HIGH,CRITICAL ...
# Every build fails. Team adds --exit-code 0 to ignore. Gate is now useless.

# CORRECT: block on critical/reachable only
- run: trivy image --exit-code 1 --severity CRITICAL --ignore-unfixed ...

# WRONG: permanent ignore buried in a config file
ignore:
  'CVE-2024-1234': true  # No expiry, no approver, no justification
# This is a silent permanent suppression, not an exception

# CORRECT: time-boxed, approved, expiring exception
ignore:
  'CVE-2024-1234':
    expires: 2024-06-30
    approvedBy: security-team
    justification: "No patch available, WAF rule mitigates"

 Dashboard metrics:

 1. Gate block rate       -- how often the gate stops a build (should be low)
 2. False positive rate   -- findings that are not real (should be decreasing)
 3. MTTR by severity      -- how fast findings are fixed (should meet SLAs)
 4. Backlog trend         -- total open findings over time (should be declining)
 5. Exception count       -- active risk acceptances (should be small and shrinking)