“From my experience, I think that Coverity improves the software quality of the NNStreamer project.”
“I manage Coverity Scan for the Tesseract OCR project Coverity Scan had be very helpful to find various bugs in the code, but since about a year it no longer allows configuring components for Tesseract OCR. That makes reports less useful.”
“As a large project with a lot of legacy code, Coverity has helped understanding the quality of that code (and confirming/refusing the developers' hunches). And of course it helps keeping quality high for the better maintained parts.”
“Coverity Scan helps us find defects in our software - which after ten years of development - are of course still to be found. While it's not perfect, it got us started and interested in fixing more issues and improving the overall stability of our project.”
“Coverity allows use to execute a weekly static analysis on the whole sources and keeps spotting issues that would go unnoticed otherwise. It's also changing the mind of developers to pay more attention about possible NULL dereference and uninitialized values.”
“Coverity remains the single most useful tool I've used.”
“Coverity's static source code analysis has proven to be an effective step towards furthering the quality and security of Linux”
“Ah, that's cool. Pretty neat that an automated tool can catch mutex lock problems in conditional statements wrapped in macros! I'm impressed.”
“You have a very good product and provide a great service to the open source community (certainly to the Linux kernel community).”
“Thank you guys for making such an awesome tool accessible to the open source community!”
Attention SCAN users! A new version of the Coverity build package is available for download. Be sure to download the new build package for your project.
Full details of new features are available at the Community Site.
Versions 2019.03 and older will no longer be supported after the upgrade.
The current supported versions are:
Users are encouraged to download the latest tools in Downloads.
Going forward, only the latest two releases will be supported. This means projects should be expected to update their tools approximately once a year (or more frequently if you want the latest features/support).
The number of weekly builds per project are as follows:
Learn how adding four principles to your Agile process can help you integrate critical security measures in a natural, efficient way.
1. Sign up and register your project
2. Upload your build for analysis
3. View and fix your defects