“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!”
Coverity 2017.07 has been released!
There are an number of checker additions and improvements for node.js as well as updated language support.
The following improvements have been made:
All users who are experiencing build issues should upgrade to this version; a number of bugs have been fixed with this release.
WARNING: Linux users on kernel version 4.8.x and newer will need to apply a sysctl parameter to support our binaries. Without this parameter, our binaries will not work on your platform. This is a known issue which we will address with a future release.
# sysctl vsyscall=emulate
Versions 7.7.0.x and older are no longer supported.
The current supported versions are:
Users are encouraged to download the latest tools in Downloads.
Going forward, only the latest three 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).
Effective immediately, the build limits have been increased across all project sizes.
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