Question: What should I do about vulnerabilities without fixes?
Tsvi Korren, field CTO at Aqua Security: Security vendors are getting better at identifying vulnerabilities and making the results available earlier in the software development cycle. Shifting left by providing vulnerability data to application developers and making them an active part of risk remediation is a good thing. However, this introduces a new challenge for security practitioners: what to do about vulnerabilities in open source components where a fix is not available or when a fixed version cannot be used due to software dependencies?
When vulnerabilities were only examined after deployment, you may have been potentially at risk, but the fact that you didn't know about them earlier at least meant you were not being negligent introducing risk into production. Now you face a few difficult options when presented with a vulnerability for which no fix exists or when a fix cannot be used:
- Stop the pipeline and potentially delay rollout of the application until a fix is available (or even bring down a deployed application).
- Task your own development team with creating a fix (assuming you have the code and the expertise) or finding a workaround.
- Move ahead accepting the risk, clearing it with appropriate compliance people, which certainly is not ideal.
Another option is to run the application in a cloud-native environment and closely control its runtime behavior. Since containers and functions are deterministic, it is possible to identify and stop execution of code that is not aligned with the workload’s intended purpose. By blocking access to specific users, commands, files, ports, or system calls, security can defang a vulnerability so that any attempt to exploit it is stopped or at least clearly identified. This ability bridges the gap, allowing application rollout to proceed, until a permanent code fix to become available.