That's a great question. This is how I would think about it:
The number of vulnerabilities by itself doesn't mean much. It has more to do with the size of the codebase and the attack surface than with the quality of the code. There is a big difference between 10 findings in 500 lines and 10 findings in 500k lines.
What matters more:
1. How bad it is and how easy it is to use. An auth bypass is not the same as a timing attack in theory. Check to see if the vulnerabilities are in code paths that can be reached in your deployment.
2. The strongest signal is the maintainer's response. How quickly do they reply? Do they take the results seriously or ignore them? A project that fixes problems quickly and gets people involved in a good way is much better than one that has no findings and no security process. For LangFuse specifically, they agreed with two of the findings and said that two of them were acceptable risks. This is a reasonable response. It's worth following up on the V4 non-response, but maintainers are busy and things get missed.
3. The kind of bugs is important. It's normal for any codebase to have logic errors, like the ones we found. You don't want to see the same type of vulnerability happen over and over again, because that means there is a systemic gap.
The only reason a project shows up in our results is because it's popular enough for us to look at it. I'd be more worried about projects that have never been looked at for security.
If you want to know more about LangFuse specifically, you can find all the information on the site: https://www.kolega.dev/security-wins/