vulnerabilities on kube-rbac-proxy v0.14.4 about kube-rbac-proxy HOT 6 CLOSED

Vulnerability is still visible with 0.15.0 image. Aqua security tool shows it specifically for go.opentelemetry.io/contrib/instrumentation/net/http/otelhttp but go.opentelemetry.io/contrib/instrumentation was replaced by PR #264

Below command shows the security vulnerability
# docker run -v /var/run/docker.sock:/var/run/docker.sock -v $HOME/Library/Caches:/root/.cache/ aquasec/trivy:0.46.0 image quay.io/brancz/kube-rbac-proxy:v0.15.0

from kube-rbac-proxy.

So you are saying that there is a vulnerability scanner, that finds a vulnerability in the dependencies, which isn't being used by kube-rbac-proxy and doesn't affect kube-rbac-proxy, but blocks your release? Oh, my...

We need a better solution for this. Time-wise it is pretty intensive to release several times a month.

I will try to make a release tomorrow (CEST). I don't want to block anyone's release.

from kube-rbac-proxy.

Yeah unfortunately I think we should reopen this ticket or create a new one to track this effort.

Many of us use trivy to scan our code, and you can even create a github action to run these scans. You could also use Dependabot to keep these packages up to date and reduce maintenance effort overall on these vulnerabilities.

So you are saying that there is a vulnerability scanner, that finds a vulnerability in the dependencies, which isn't being used by kube-rbac-proxy and doesn't affect kube-rbac-proxy, but blocks your release? Oh, my...

Yeah while it gets to be a pain since we are bound to have transient dependencies that have vulnerable code we don't use in them, I've learned that many companies track vulnerable packages that their software imports regardless of whether they can be exploited. In the end, The general idea is that when it comes to library packages with vulnerable code, even if you don't use the code today, there's always the risk that a future commit will. No developer can really know if the method they are using from a library is vulnerable while they are adding it in so they can't be expected to worry about that while they are writing their code. I'm not aware of IDEs smart enough to track this and warn you. The best we can do today is to keep our packages up to date using tools like Dependabot, so that we can spend less time worrying about package management and vulnerabilities.

from kube-rbac-proxy.

With found, you mean that you have a working example of it being abused?
Checking the description of the CVE, I don't see a codepath that would affect kube-rbac-proxy.

If it would be a high severity CVE that affects us, I would drop everything and fix it right now. As it doesn't look like so and in the context of http/2 discussions going on, I might still create another release this week, which would replace the dep.

from kube-rbac-proxy.

I do not have any working example of it being abused. But with this high vulnerability, we could not use and deploy this release.

from kube-rbac-proxy.

Sorry, i was to tired yesterday, but it should be fixed with v0.15.0

from kube-rbac-proxy.