1

Docker and other container images have become important building blocks especially for software production pipelines. Unfortunately, several researchers (e.g. BanyanOps) have shown how vulnerable docker images can be , including those from the official distributors. I was researching into the possibilities for automatic patching of such vulnerable images when discovered. According to this link, container patching is very sensitive and error-prone. Infact, there seems to be no solution as all the papers/reports about container image vulnerabilities do not proffer patching approaches. I will be grateful if someone has some opinions, options or even a possible solution.

Note: I am interested in how patching is conducted with or without update notifications.

  • @030 the issue of how to patch was not discussed there. The closest was getting notifications for patches. I am interested in how patching is conducted with or without update notifications. – SyCode Feb 26 '18 at 23:35
  • wait but what does mean patching here? if this is about other libraries, you just exchange the image. Please elaborate more on scenarios which bring you in trouble. – Peter Feb 27 '18 at 7:59
  • @PeterMuryshkin yes exchanging the images i.e. updating the Dockerfiles to reflect the non-vulnerable packages. For example if the you update an image from Java 8 to Java 9, the application built into the eventual container might not be compliant with Java 9. Therefore there might be some extra steps e.g compatibility tests. So, this gets more complex for large pipelines, and automation becomes handy. Are there methods that deal with this kind of challenge or someone has some experience to share. – SyCode Feb 27 '18 at 10:17
  • @SyCode oh I see I thought on more granular level like you find a vulnerable JAR and in a DevOps culture developers are able to fix it. Moving from Java 8 to Java 9 means to me rather an organizational migration decision which needs to be properly scheduled: this is more than just a patch. – Peter Feb 27 '18 at 10:49
3

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.

  • 1
    though your answer is high-level it provides some clarity. So this is purely DevOps - culture. I'd really like to understand the low level stuff also but probably with more research into the tooling approaches and best practices. Thanks :). – SyCode Feb 27 '18 at 12:13

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.