RFE: Implement "scan" command to surface known package vulnerabilities

[wagoodman]

Is this a BUG REPORT or FEATURE REQUEST?

/kind feature

Description
It would be ideal to have a scan command that surfaces known vulnerabilities for packages within container images, mimicking the new docker scan command.

I work on a CLI tool, Grype, that is written in go that can fulfill this functionality. Today grype does not depend on shelling out to get information for packages and vulnerabilities --all functionality is contained within the grype binary, with all dependencies 100% in go (no CGO required). Between this and the fact that grype was meant from the beginning to be used as both a CLI tool and a library makes it an ideal candidate for incorporating vulnerability detection functionality for a scan command.

There seem to be two ways to approach integrating grype and podman to provide the podman scan functionality:

1. Pull in grype as an in-source-tree go dependency, embedding grype into the podman binary. I have a branch prototyping out the necessary changes.

2. Manage the grype binary separately. In this approach podman would download and manage the grype binary in an internal podman directory and invoke grype by shelling out to the binary and obtaining the results from json output.

In both approaches:

• the ImageEngine.Save functionality would be used within the scan command to obtain an image archive and feed into grype.
• the vulnerability database (a sqlite file) would be managed by grype in an internal podman directory, updated daily from publicly available data derived from https://ancho.re/v1/service/feeds .

I would be happy to collaborate with folks here on the desired approach and make contributions to grype and podman as-needed!

[vrothberg]

Thanks for opening the issue!

We recently added a new image mount type which was motivated by your use case (i.e., image scanning). Doing a podman run --mount type=image,fedora,/fedora will mount the "fedora" image at /fedora inside the container.

So you can use the mechanism to use pretty much any scanner on any image. I have not had a look at docker scan yet but it sounds like something opinionated with a baked in scanner. There are many scanners out there in the wild.

In other words. If you have scanner and want to run it, you can put it into an image, and use it to scan other images.

[vrothberg]

@rhatdan PTAL

[rhatdan]

I like the idea of having a podman scan command to match Docker, but I would not want it to be opinionated.
@baude @mheon Thoughts?

[mheon]

I'm not opposed to providing a native command, but ideally I'd want to design it such that multiple scanner backends were supported - a plugin system would be ideal (or, barring that, just ensuring everything is behind an interface so we can easily add new implementations).

My primary concern around including a scanner directly in Podman boil down to binary size - if this ends up pushing our binary size up by 10mb, that's not really a good thing (and makes me lean more towards doing this as a plugin, though the complexity in developing a plugin interface will be significant).

[vrothberg]

I wouldn't like a security scanner to be part of the code base. As mentioned earlier, we have the --mount type=image mounts that can easily be used. A podman [image] scan could internally do a podman run --mount type=image ... security/scanner/image:latest with "security/scanner/image:latest" including the security scanner.

Users can easily user their security scanner of choice, Podman wouldn't ship a security scanner but only run it an image (no binary bloat, maintenance burden, ...). The image could be configurable on the CLI and via containers.conf.

[wagoodman]

@vrothberg I like this approach --this seems like a good way to keep the grype dependencies/build process untangled from podman 👍 .

[vrothberg]

Wonderful! Would you be interested in contributing the feature, @wagoodman ?

[wagoodman]

I am! I think I'll be getting a bit more time in a week or so, I'll update here with a branch or draft PR closer to then.

[vrothberg]

Great, thanks! Feel free to join #podman on IRC (Freenode) if you want to reach out.

[wagoodman]

Hey @vrothberg , found some time today to take a stab at prototyping.

I started with adding a new cmd/podman/images/scan.go which references cmd/podman/common/* functionality. Podman run seems to be leaning on several default values that are baked into the cobra flags, so for this reason they are leveraged and exposed on the scan command as well.

The draft PR is here: #8706

Things left todo:

• make a PR in github.com/containers/common to expose a new configurable in containers.conf. I haven't identified where the change should be (maybe here?) or what it may look like yet.
• add configuration and CLI option to potentially modify the mount value passed in (optional, could probably live without this)

Questions:

• are we OK with create/net commands being exposed on the scan command? I couldn't think of a reason not to include them.

Let me know if this approach is OK or if I should be making some direction changes. Thanks!

[vrothberg]

Thanks a lot, @wagoodman! Much appreciated 👍

I am going to have a look now but will comment over in #8706.

[github-actions]

A friendly reminder that this issue had no activity for 30 days.

[rhatdan]

This is still being worked on.

[github-actions]

A friendly reminder that this issue had no activity for 30 days.

[wagoodman]

This is still being worked on.

[github-actions]

A friendly reminder that this issue had no activity for 30 days.

[rhatdan]

@wagoodman Any update?

[github-actions]

A friendly reminder that this issue had no activity for 30 days.

[rhatdan]

@wagoodman Any progress?

[github-actions]

A friendly reminder that this issue had no activity for 30 days.

[github-actions]

A friendly reminder that this issue had no activity for 30 days.

[github-actions]

A friendly reminder that this issue had no activity for 30 days.

[github-actions]

A friendly reminder that this issue had no activity for 30 days.

[vrothberg]

@rhatdan that topic came up on the mailing list. My guts tell me that may be something for @cdoern to work on. A cool feature and I smell a great blog post :)

[rhatdan]

I really do not see what value we are adding with podman scan other then mounting the image and potentially launching a third party app? Why wouldn't you just script this?

[vrothberg]

I really do not see what value we are adding with podman scan other then mounting the image and potentially launching a third party app? Why wouldn't you just script this?

It makes the life of users easier (same as --all,--latest,--replace etc.) A desire for built-in security scanner for images popped up here and there. IMHO it's check-box security: build + scan + push ✔️

The docker-scan plugin, for instance, is able to detect the log4j vulnerability: https://docs.docker.com/develop/scan-images/

[rhatdan]

We did used to have the atomic scan tool, which would launch a containerized scanner with an image mounted into the container available for scanning.
I guess this could be a summer intern project or a contributor could work on it.

[github-actions]

A friendly reminder that this issue had no activity for 30 days.

[vrothberg]

@ashley-cui, a potential intern project.

[rhatdan]

I think we would need to do a big design discussion on this one, to figure out what this even is required.

[vrothberg]

@rhatdan are you still interested in the scan command?

[rhatdan]

This would probably come under the banner of plugins. Making it easy for others to build a scanner plugin would be an issue.

[umohnani8]

Will continue the conversation in the plugin issue #13461