2

Is there a good best practice for container vulnerability management when you are not a dev shop?

I am currently trying to figure out how to set up a proper supply chain risk management system for a company that only consumes docker images as a standard deployment model but does not have any inhouse dev capabilities.

To manage that properly, as a dev org, you would pull the Dockerfile for your base image and build the image yourself, including vulnerability scanning, SCA and SAST. This image is stored in your own registry and you use that image as the base image.

Is there any other way that does not include running your own registry, rebuilding all images on your own and deploying these?

Rohit Gupta
  • 301
  • 2
  • 4
  • 14
Stefan Lorenz
  • 383
  • 1
  • 10

2 Answers2

0

The container scanning piece of this can be done quite easily without running your own registry, just using Open source tools (e.g. Trivy), but to address issues noted, you've only really got a couple of options

  1. Get the image owner to update (either by filing an issue with an open source project or speaking to a vendor for commercially supported images)
  2. Update the image yourself.
  3. Switch to a better maintained image that provides the same capabilities

For option 2 there, you don't have to run a full registry yourself, you can just get an account with a registry like Docker Hub, and then clone/patch the images into that account.

For option 3 there's not really a generic answer on exactly how you'd do that, as it depends on the specific software and images in question. In some cases you might find a wolfi image that meets your needs. They are designed to be regularly updated, possibly avoiding the problem.

Rory McCune
  • 62,266
  • 14
  • 146
  • 222
0

I'd build a layered approach, based on what you are capable of. Even development organizations don't have all the resources needed to take all possible actions.

Start with supplier management. When you use any externally produced products, you need to understand who is making it. Does the supplier have policies and procedures to mitigate risks? Do they have controls over who can contribute to open-source projects? Do they scan and remediate vulnerabilities? Does the supplier engage with users or have a user community that supports each other? Favor products that have these types of controls in place.

Consider keeping local copies of artifacts to mitigate unexpected changes or errors. This goes beyond vulnerabilities, but broader supply chain issues where a version can be unexpectedly removed from external repositories or a reference to a version can result in uncommunicated/undocumented changes. This applies to everything from open-source projects to containers to packages. Hosting your own artifact repository on your infrastructure does require IT support, but there are also SaaS solutions.

Scan the artifacts that you use yourself. Engage with the supplier to understand findings or report findings as issues. If a finding is a true positive, apply mitigations. Just because a vulnerability exists doesn't mean that it can't be mitigated in other ways. Reducing the footprint of the vulnerability may be enough to reduce the risk of using vulnerable components.

Thomas Owens
  • 1,072
  • 8
  • 9