A Release Gate That Teams Route Around With a Shared Admin Account
A product company with 14 teams and 60 developers deploys about 900 times per week through a shared pipeline that runs static analysis, dependency scanning, and container image scanning. The pipeline blocks any build that reports a high or critical finding. Thirty-eight percent of builds are currently blocked, and post-hoc triage shows that 71 percent of blocks were findings in unreachable code, test fixtures, or dependencies not loaded at runtime. Teams have been bypassing the gate using a shared administrator service account whose password is posted on an internal wiki page; there were 112 overrides last quarter with no ticket or follow-up. The registry holds 1,200 images, 400 of which are unsigned, and 60 services still build from a base image last updated two years ago that now carries a critical remote-code-execution vulnerability. Leadership wants the override removed immediately and the vulnerable base image banned at deploy time.
1. Leadership wants the override removed and the vulnerable base image banned at deploy time, immediately. What do you do in the first two weeks, and what do you push back on?
Read the worked answer
Separate the two demands, because they carry different risk.
The base image: fix it, do not just ban it. Rebuild the base image with the patched package, publish it under a new tag with an SBOM, and open automated pull requests against the 60 services. Then enforce at admission: block images built from the old base digest or carrying that CVE. Enforcing before a fix is available would stop 60 services from deploying, and teams would respond by routing around the control again, which is exactly the failure you are trying to end. A short, dated grace window with a fixed remediation date is defensible; an immediate ban with no path is not.
The override: do not simply delete the shared account and declare the problem solved. That account is the only working release path for 14 teams, so removing it on day one converts a governance problem into an outage and pushes people to a less visible workaround. Instead, in the first two weeks, disable the shared password, rotate it, remove it from the wiki, and replace it with a per-person, time-boxed break-glass that requires a ticket and notifies the security channel. That preserves the escape hatch while making it attributable. Deleting the mechanism entirely should wait until the false-positive problem is reduced, which is the root cause of 71 percent of the blocks.
Push back on: immediate full enforcement, and any framing that treats developer behavior as the primary defect. The gate is producing mostly noise; people route around noise.
2. Redesign the release gate so that it blocks real risk without generating the current false-positive rate. Be specific about what changes.
Read the worked answer
Change what the gate measures, when it measures it, and what it does with the answer.
What: add reachability and exploitability context. A high-severity finding in a test fixture or an unreachable code path is not the same risk as a reachable deserialization path in a deployed service. Enable the scanners' reachability analysis where available, exclude test directories at the policy level, and classify findings by whether the dependency is actually loaded at runtime.
When: move to differential gating. Block on new findings introduced by the change, and put the pre-existing backlog on a tracked remediation plan with owners and dates rather than blocking every build forever. Teams cannot fix 900 builds a week of accumulated debt, and pretending otherwise is what caused the bypass.
What it does: gate by policy tier. Critical and exploitable findings block. High findings create a time-boxed ticket and a warning. Low and informational go to a dashboard. Define the policy as code, version it, and announce changes in advance.
Also add the controls the current pipeline lacks: sign images in the build, verify signatures at admission, pin base images by digest, generate an SBOM per image, and scan the registry continuously rather than only at build time. Continuous scanning catches the base image drift problem that build-time scanning misses once an image is already running.
Measure the gate on precision, not on block count. Publish false-positive rate, mean time to remediate, and override count as the health metrics.
3. Design the override mechanism that replaces the shared administrator account. What controls make an override acceptable rather than a bypass?
Read the worked answer
An override is acceptable when it is attributable, justified, time-bound, visible, and rare. Design for those five properties.
Attributable: each engineer authenticates as themselves. No shared credentials, no password on a wiki. The override permission is a role granted to named individuals, reviewed quarterly.
Justified: requesting an override requires a ticket with a written reason and the specific finding being waived. The pipeline records the ticket ID against the build, the image digest, and the commit.
Time-bound: the override approves one deployment of one artifact, not a standing exemption. It expires automatically, and the next build must justify itself again. Recurring waivers for the same rule escalate to the security team after a threshold, for example three in 30 days, because recurrence is a signal that the rule is wrong or the fix is not being prioritized.
Visible: every override posts to a channel the whole engineering organization can see, with the reason and the ticket. Security reviews the override log weekly and reports the count and the top recurring rules to leadership.
Rare: the mechanism only works if the gate is worth obeying. Continue reducing false positives and keeping remediation paths short, or the sanctioned override becomes the default release path.
Also monitor the override rate as a leading indicator. A sudden rise usually means a scanner rule change or a broken remediation path, not a sudden drop in engineering discipline.