Our team has lengthy release cycles, and the security backlog grows significantly between releases. Even when we use hardened base images, new vulnerabilities accumulate before the next deployment. Because we're a small team in a regulated industry, and management isn't currently willing to improve collaboration between development and security, much of my work has become responding to individual tickets. We're meeting with the security engineering director soon. What runtime or compensating controls could reduce the risk while we work toward shorter release cycles?
3 Answers
The best long-term fix is separating security patching from feature releases. Rebuilding the base image and redeploying without changing application functionality creates a small, reviewable change that may qualify for a lighter validation process, even in a regulated environment. That is likely a more practical proposal than trying to accelerate every part of the release train at once.
Use the term “compensating controls” and reframe the backlog around actual risk. Many scanner findings affect packages that are present in an image but never loaded or reachable. Prioritize vulnerabilities using exploitability signals such as active-exploitation status and likelihood scores. A large list may shrink to a much smaller set of urgent issues, making the discussion about measurable risk instead of raw ticket volume. Ask for risk-based remediation targets with documented exceptions rather than an unrealistic blanket deadline.
Runtime controls can buy time, but they won’t eliminate the backlog. Consider admission policies that only allow workloads built from approved hardened images, network segmentation to limit what a compromised service can reach, and virtual patching at the web application firewall for relevant internet-facing vulnerabilities. Treat these as temporary risk reduction while fixing the release process, not as a substitute for patching.
Our release process is slowed by legacy dependencies between teams, and management has only planned to address that next year. I’m concerned that separating application and base-image updates could simply create two different vulnerability cycles, but it may still be easier to manage if the base-image path is automated and clearly governed.