In the fast-paced world of cloud-delivered software, security remediation is critical to the success of your organization. Investing in tools to detect application vulnerability and infrastructure misconfigurations is important, but the only way to truly benefit from the effort is to fix the issues quickly and close the risk window before it’s too late. Unfortunately, many organizations make three big mistakes when it comes to security remediation: not fixing things at the source, not propagating the remediation, and waiting to get detection and visibility perfect before getting started.

‍

The first mistake is not remediating security issues at the source. Take vulnerabilities in container images. When developers create applications, they sometimes start with a base container image and, from it, derive application-specific container images. The base image might contain a programming language or framework, an operating system, and system libraries, and derived images might include the base image, plus code specific to the application and configuration files. Base image system libraries are the source of many of the security vulnerabilities we hear about in the news. When this happens, the developer can either fix the base image itself or write instructions to update the system library in the derived image. Too often, they choose the latter because they can implement it faster, don’t have to track down the owner of the base image, and don’t have to take on the risk of having to updating the base image (which is part of other derived images), possibly leading to unforeseen problems in some other application. Even though those reasons make sense to some extent, fixing the derived image is still not a great choice. True, it addresses the vulnerability in that application, but it leaves the base image unchanged, so all other derived images inherit the vulnerability. The right choice is for the code owner of the original base image to fix the problem at the root. If you have a platform like Dazz in place, you can be certain of that root cause, know exactly where to fix it at the source, and identify the code owner. Armed with those key pieces of information, you can fix the problem once and for all.

‍

The second mistake is not seeing the remediation through all of the way. Even if you remediate the issue at the source, you still need to propagate it through your pipelines and promotion processes. If you’re dealing with container vulnerabilities, this means rebuilding the base container image, pushing it to the container registry, and then rebuilding the derived application container images. This can be difficult as it requires orchestration between several teams, including platforms, applications, and DevOps. Organizations may also be affected by the vulnerability if they have a diverse set of images deployed at the same time, with some applications being built on older base images. To avoid this, make sure you address all dependent container images and codify the propagation portion of the remediation process, which should be a best practice in your organization.

‍

‍

The third mistake is waiting until your detection and pipeline visibility are perfect before you begin remediating issues. Chasing the dream of perfect visibility can be dangerous, as it leaves your organization exposed to risk for longer periods of time than getting started early. Instead, start fixing the things you can see right away. Using a platform like Dazz gives you the root causes and remediation guidance (either automated or controlled by you) so you can begin reducing risk immediately. This has the dual benefit of mitigating risk of breach or exposure and helping you fine-tune your platform and remediation process.

‍

Remediating cloud security issues efficiently is critical to the success of your organization. Make sure you fix problems at their source, see remediations through, and start remediating even before achieving perfect visibility.