CI/CD gating at 38 percent failure rate: the gate everyone bypasses

A gate that fails 38 percent of builds is not strict; it is ignored, and an ignored gate provides less assurance than a narrower one that is actually enforced. The defensible design is a small, stable, explainable blocking set plus full visibility for everything else.

• Block: secrets detected with high confidence; newly introduced IaC findings that create public exposure (public bucket ACL, 0.0.0.0/0 on 22 or 3389) on production paths; critical or high fixable CVEs in an image bound for production where a fixed base or package exists.
• Warn, with a dashboard and an owner: no-fix CVEs, low and medium IaC style rules, dev-account wildcards, license findings.
• Differentiate by context: pull requests warn and comment; merge to main and release tags block. Environment matters more than severity alone.

Auditor framing is straightforward: the control is enforced in the pipeline at the point of artifact creation, evidence is retained per build with the policy set version, exceptions are recorded with owner and expiry, and the policy set is versioned in Git so changes are reviewable. A gate with a documented scope and 100 percent enforcement beats an unbounded gate that developers routinely skip, and auditors will accept that reasoning if the scoped set covers the risks that matter.

Treat it as an image lifecycle problem first, because that is where most of the volume disappears.

1. Rebase onto a maintained image (current Debian slim, Alpine, or distroless) and rebuild. Two-year-old tags accumulate unfixed packages that a fresh pull often resolves without code changes.
2. Rebuild on a schedule so patched packages are picked up even when application code does not change; add the base-image bump as an automated pull request so it is cheap.
3. Where a vendor backport exists, consume it; where the team must stay on the image, apply the vendor patch layer.

For what remains, risk acceptance must be documented, not silent. Record owner, business justification, the compensating controls (network egress restriction on that workload, runtime policy blocking shell and network tooling in the container, WAF in front of the exposed service), and an expiry of 90 days. Automate re-evaluation so the exception is reviewed when a new base image publishes rather than when someone remembers.

Use exploitability signals, not CVSS alone: whether the vulnerable library is loaded, whether the function is reachable, and whether exploit code is in the wild all change the ranking. The KPI to report is fixable critical and high findings in production images, targeted at zero, with no-fix acceptances reported separately and honestly.

Bypasses exist because the compliant path is slower than the workaround. Fix speed and observability together.

• Make the right path cheap: a one-click waiver that generates the exception record, an automated base-image bump pull request, and inline fix suggestions for IaC so a developer can clear a finding in the same commit.
• Make bypass visible, not shameful: collect pipeline telemetry for skip flags, ignore-file changes, and build systems that are not integrated. Inventory every build system by API or repository scan so the unintegrated Jenkins controller appears on a list rather than being discovered during an audit.
• Enforce where it cannot be skipped locally: require the scan as a branch-protection status check in the SCM, so a local skip flag does not produce a mergeable change.
• Keep the policy set in Git with pull-request review, so rules cannot be edited quietly by one person in the console.

Note for the risk discussion: skipping a CI scan does not remove registry or runtime image scanning coverage, so the exposure is a later detection rather than none. Say that plainly, then hold the line on the blocking set and report exception counts monthly to engineering leadership. Punitive escalation converts a tooling problem into a concealment problem.