The Security Gate Everyone Bypasses
A 14-team SaaS company runs a CI/CD pipeline with a security gate that blocks releases only when a critical vulnerability is found. Last quarter 38% of releases used an emergency exception approved by whichever security engineer was on call; most approvals happened between midnight and 4 a.m. Median time to remediate criticals is 47 days, and 22% of exceptions are never closed. The company just acquired a firm with six teams and a different scanner. A product VP wants the gate removed to hit a launch date. Engineering says the gate "adds no value."
1. Diagnose what the exception rate is telling you and decide whether to remove the gate.
Read the worked answer
A 38% exception rate is not a discipline problem; it is evidence that the control is badly designed. The gate sits too late, blocks on findings the team cannot fix in the release window, and delegates approval to a single tired engineer with no context and no authority to say no. Exceptions become the normal path.
Removing the gate trades a noisy control for no control and leaves the company unable to evidence release decisions to customers or auditors. The better move is to redesign it:
- Scan earlier in the IDE and pull request so findings arrive when they are cheap to fix.
- Tier thresholds by exposure: internet-facing services with exploitable criticals block; internal low-exposure findings create tracked debt with owners and dates.
- Replace free-text emergency approval with policy-as-code and time-boxed exceptions carrying a named owner, justification, and expiry.
- Require two approvers above a defined risk threshold and add post-hoc review for break-glass releases.
The VP's launch date and the gate are not actually in conflict; the current process is.
2. How should the acquired company's six teams be brought into the lifecycle?
Read the worked answer
Do not grandfather the subsidiary or force an immediate tool migration; both create blind spots.
First, inventory and baseline: what they build, what data they touch, their current scanner coverage, and known criticals. Second, set a single policy with a 90-day convergence plan: their scanner feeds the same exception register and the same severity definitions from day one, even if the underlying tool differs. Third, assign security champions in each acquired team and a named accountable owner on the integration. Fourth, run a joint tabletop on a critical finding to test whether the process works across organizational boundaries.
Watch for the predictable failure: acquired teams bypassing controls because they were never told the rules, while the parent company assumes coverage it does not have. Measure coverage explicitly and report it to the integration steering group.
3. Which metrics should the CISO use to show whether the redesign worked?
Read the worked answer
Raw vulnerability counts reward noise and punish honest reporting. Use a small set tied to the control's purpose:
- Exception rate and exception age - the core signal; target a falling rate and no exceptions past expiry.
- Percentage of criticals remediated within policy SLA, split by internet-facing and internal.
- Time from finding to first human decision, which shows whether findings are being triaged or ignored.
- Reopen rate, catching fixes that did not hold.
- Coverage: percentage of repositories and acquired teams actually scanned.
- Percentage of releases blocked with no exception, a proxy for whether the gate is credible.
Review monthly with engineering leadership, not just security. If exception rate stays high, the answer is process design, not stricter enforcement language.