ProGet: implement Policies & Blocking support for Container feeds

[Nils Nilsson]

Hi!

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

[apxltd]

Hi @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,
Alex

[Nils Nilsson]

Hi Alex,

Thanks for taking the time to respond to my request.

I fully agree that individual vulnerabilities are often not relevant for a container image.

The problem arises when we can not make distinctions when assessing, as we might never be able to assess a vulnerability using the global scope.

A scaled down example could be that we have two feed groups, each with their own Package Policy. 'External' which is used for the build/store of an application served to external users comprised of the general public(i.e. a web service), while 'Internal' is used for an identical but separately generated application that is run strictly for internal users with no exposure to the internet.

External:
Universal Feed, Nuget feed, Container feed

Internal:
Universal Feed, Nuget feed, Container feed

Then we might have a vulnerability like PGV-255532C, assuming we in our application are using the functionality of sqlite which is affected.
This would pose an unacceptable risk for an application reachable and used by external users, while it could be fine for an internal application.

The current assessment structure for containers wouldn't allow us to continue using the container in the 'Internal' feed group, without also allowing the container in the 'External' feed group.

I agree on the premise that an Image is more like a Build, than it is a Package. But even then sharing policies between containers and package feeds would remain relevant for our usecase.

Best regards
Nils Nilsson