As this question is quite high-level, I give a high level answer.
Technically, if there is an incident, you would normally enforce a shutdown of a running container and a replacement with a newer image with an implementation of the change request resulting from the incident.
How much automation will be possible to get there, I think it really dependends on single cases or at best their classes.
Best is therefore I think to assess different scenarios, group them into classes and derive solution workflows. Once a problem catalogue and a required set of organization policies are there you will be able to sort out which tools can help to realize them and which automations grades are possible.
For example:
- discovered system environment level vulnerabilities are normally patchable through operation system security upgrades. You could have batch job delivering daily updated base images.
- application environment level changes like "let's migrate from Java 8 to Java 9" is an organizational decision which requires an organizational process
- application code level vulnerabitites requiring updating to patched versions requires some ways of dependency management governance in your organization, tools for quality gates are available but without an organizational decision nothing will happen here.
- default credentials in production - again where do they come from? This is very special case and possibly a design failure; not sure how solve this in an automated way.
So I have to conclude that this question is more about culture than automation.