My organization has departments/products with various risk aptite and regulatory requirements.

We need to be able to assess vulnerabilities in containers per feed/policy, in the same way that can be done for 3rd-party components.

Best regards
Nils Nilsson

We're considering "doing something" about this for our ProGet 2027 roadmap, but I really want to think about how this should be handled in ProGet. I want to create something that actually is helpful in identifying real security risks... and I'm not sure if our package-intended Policies is the move for Docker containers.

One major issue is that nearly all vulnerable packages in a container IMAGE pose zero risk. Even if the component were used (most aren't... they're just installed), exploitation would require someone SSH'ing into the container and running interactive commands. PGV-2387734 is a great example of this.

It's actually more risky to remediate the vulnerability and become "sensitized" to vulnerabilities like this. So, we want to make sure we can find way to "permanently mute" these for certain containers - and perhaps that involves saying "I do not actively use this component that happens to be installed in the image"? I'm not sure.

There are also some issues with the ways vulnerabilities work with certain Linux distros; for example, the "patch version" varies by operating system, and that information isn't readily available in the vulnerability database and ProGet isn't analyzing which operating system the platform is using.

We have a rough idea of treating Docker images to be more like SCA Builds than Feed Packages, in that an entire container image would be considered complaint. However, how many container images are built (it's done at CI for a lot of people), how few people seem to use pre-release tagging, etc., I don't know what makes sense here.

Anyway let me know your thoughts!

Thanks,
Steve