Critical & High Security vulnerability issue with Trivy Scan in postgres 16

[sathyendranv]

Hi Team,

Postgres 16.x and 17.x has some Critical and high vulnerability reported. Can you confirm if there are any fixes planned in pipelines or these issues are false positive.

Thanks.

Postgres 17.2:

Postgres 16.6:

[tianon]

See #1295 (comment)

(Duplicate of #1271 Duplicate of #1292 Duplicate of #1295)

[probitcarwyn]

While I completely agree that the root cause here is the naive "security scanners" inability to delve into the details and work out if there is a real vulnerability, the reality is that this is where many of these tools are at the moment.

One such "naive" scanner is Docker Scout. A glance at the Docker Hub tags page for this image lights up like a Christmas tree with High and Critical (all of which I believe are false positive):

• https://hub.docker.com/_/postgres/tags

As an image that is part of the Docker Official Image which is supposed to serve as the starting point for the majority of users, is it realistic to expect users to know they need to delve into govulncheck to figure out if the vulnerability is real? Given this is a postgres container, they may not even be using Go in their toolchain.

The Docker Official Image page goes on to say:

The images are some of the most secure images on Docker Hub. This is particularly important as Docker Official Images are some of the most popular on Docker Hub. Typically, Docker Official images have few or no packages containing CVEs.

So there's a certain expectation being built up here, which is at odds with what users see via the Docker Scout output.

While it certainly seems true that these reports are false positive, that's not the perception people will get from what is arguably the primary location people will be picking this image up from (Docker Hub).

Granted the Docker FAQ entry Why does my security scanner show that an image has CVEs? does say:

It is up to individual users to determine whether not a CVE applies to how you are running your service and is beyond the scope of the FAQ.

Is there a way to prod Docker Scout to be smarter or otherwise mark false positives there?

[abhisheke1mishra]

I agree about false positive but my Org doesn't. They kept publishing as a Vul and asked me to fix before we put it in Prod.
So as a last resort, I took the gosu source code (Since its open source) and build it on go 1.22.4 which is free of vulnerabilities and used the updated gosu in my postgres build, which came out vulnerability free.
Only problem is I've to this 1 additional step every time I want to update to latest version.

[jesperronn]

@abhisheke1mishra

So as a last resort, I [built gosu] on go 1.22.4 which is free of vulnerabilities and used the updated gosu in my postgres build, which came out vulnerability free.

Thanks for your workaround. I agree that our companies vuln policies are stricter and it takes unnecessary resources if everybody have to assess false positives all the time.

If possible, could you:

1. please provide the example code workaround here
2. please suggest a PR for this project with the updated build on go 1.22.4 or whatever is the most recent