Dev rejects CVE severity, makes his GitHub repo read-only

Re:Dev rejects CVE severity, makes his GitHub repo read-only by throwaway_62022 on Sunday June 30, 2024 @12:41PM (#40838195)

Ugh - say I wrote a daemon that runs every 2 hours, it exposes no end points and has no metrics. But just because I depend on some library that brings in promethus which in turn brings some http2 library, I am on the hook for fixing this Cve in my code.

Shouldn't it be on security researcher to prove that how this can be exploited if no http end points are created?

So much of security scanning is such bullshit.

[ Parent | on HN ]

Re:Dev rejects CVE severity, makes his GitHub repo read-only by mschuster91 on Sunday June 30, 2024 @12:45PM (#40838227)

> Shouldn't it be on security researcher to prove that how this can be exploited if no http end points are created?

The problem is, from their viewpoint the security researcher is completely correct: a vulnerability is a vulnerability.

Consuming applications absolutely have to do their own research for CVEs in dependencies, to determine if they are impacted or not, and to develop mitigations on their side as well if needed.

[ Parent | on HN ]

Re:Dev rejects CVE severity, makes his GitHub repo read-only by philipwhiuk on Sunday June 30, 2024 @12:47PM (#40838232)

> The problem is, from their viewpoint the security researcher is completely correct: a vulnerability is a vulnerability.

In the app using the library, not in the library.

[ Parent | on HN ]

Re:Dev rejects CVE severity, makes his GitHub repo read-only by dogma1138 on Sunday June 30, 2024 @01:31PM (#40838565)

Sure, but if you are using the library is there is no way to disclose vulnerabilities within libraries you have no idea if you need to implement mitigations or not.

There is no good solution here but not allowing CVEs to be assigned to libraries is by far the worst one.

[ Parent | on HN ]