Our release cycles are extremely long, and the security backlog grows between releases. I'm spending more time responding to tickets than doing productive work. Even when we use hardened images, new vulnerabilities accumulate before the next release. We're a small team in a regulated industry, and management hasn't been willing to improve collaboration with security. We're meeting with the director of security engineering soon—are there runtime or other compensating controls that could reduce the risk while we work through the backlog?
3 Answers
A hardened-image provider or a continuously updated base-image pipeline might help, but changing vendors won’t solve the process problem by itself. You still need a policy for which findings are actionable, an expedited path for security-only rebuilds, and evidence showing how runtime controls reduce exposure while patches are pending.
It’s also worth asking why the release process is so tightly coupled. If legacy dependencies make a full breakup unrealistic, start with one separable path—such as independently rebuilding the base image and redeploying unchanged applications. That avoids creating completely separate, unmanaged vulnerability cycles for the application and its image while still shortening the security feedback loop.
Yes—“compensating controls” is the right framing for that meeting. Start by prioritizing findings based on actual exploitability instead of treating every scanner result equally. Cross-reference active exploitation, such as CISA KEV, with EPSS and whether the vulnerable package is actually loaded or reachable. A backlog of hundreds of findings may turn into a much smaller set that needs immediate attention. That shifts the discussion from ticket volume to measurable risk.
Ask for a risk-based remediation SLA rather than simply demanding faster feature releases. In a regulated environment, the important thing is often documenting why a risk was accepted, what controls are in place, and when it will be reassessed.
The longer-term fix is to separate security patching from feature releases. Rebuilding the base image and redeploying without changing application functionality is a small, reviewable change, so it may qualify for a lighter validation path if your compliance process allows it.
Runtime controls can buy time: enforce admission policies so deployments come only from approved, current base images; use network segmentation and least privilege; and apply virtual patches through a WAF for relevant internet-facing vulnerabilities. These controls reduce exposure, but they won’t eliminate the underlying backlog.
The main problem is legacy code with lots of team-specific dependencies, and management has moving this up the priority list next year. My concern is that splitting the process could just create separate application and base-image vulnerability cycles.