How do we feel about Coverity Scan?

Some years ago I played a bit with Coverity Scan for some personal (admittedly toy) projects and it looked like a good way to find hard to spot memory bugs (it catches a few more things IIRC, but those were the ones it shined the brightest).
There's a free service for open source projects that we could take advantage of and in my experience it's far more sophisticated than tools like cppcheck, and slightly better at finding bugs than clang-analyzer.
Go and Java are also supported, so it could also be useful for implementations on those languages.

The downsides:

1. Maintainers may be uncomfortable with relying on closed services;
2. It would be advisable to keep only a few developers on the loop, due to the risk of 0-days leaking before they're fixed otherwise. This could have some undesirable side-effects, some regular contributors may feel left out, picking who should or should not see the results could be hard, etc. The impact on the morale of the community could be bad (or I may just be too worried over nothing);
3. There's a limited number of builds per week. For the size of the project, it would be 28 builds a week, so a cron-like arrangement over main would probably be a better approach than, e.g., running on every PR.

So, what do other devs think? I'm interested in @lemire's opinion specially.

No files or tests are named. Start by reviewing the Coverity Scan proposal and the project's existing build process, then assess service access, security concerns, supported languages, and the weekly build limit; done means a decided integration plan or a documented decision not to proceed.