Coverity Reviews

We did a comprehensive evaluation on a number of critical parameters in the environment that we are in. Other popular tools that we evaluated failed to meet our expectations.

• Ease of development teams to adopt.
• Faster scanning
• Lowest false positives
• No unnecessary bloating of a huge defect list.

These have helped us to focus on the things which need attention.

• Lowest false positive rate
  
• Faster scanning time
• Inline context-sensitive help and other supportive artifacts which help developers.
• Customizable triage options
• Integrations with CI/CD tools, etc.

• Reporting engine needs to be more robust.
• Custom reporting is a must have.
• Perhaps, the availability of connectors to popular open source BI tools, such as BIRT, JasperReports, or Pentaho may add value.

We write thousands of lines of code on a daily basis, and we cannot say that our code is free because there are a lot of other developers contributing to the source code and things like that. And this process is prone to human error, defects in the source code, etc.

To automate detection, we use Coverity's static analysis, which has a low false-positive ratio. That's because Coverity's analysis engine includes 20-plus patented technologies. A lot of other static analysis tools use pattern-based analysis, but Coverity's is flow based. That's why we ended up using it. Coverity is helping us identify some of the critical defects at the early stages of the development life cycle. So overall, it is giving us a greater ROI and making our application more mature and robust.

One of the most valuable features is Contributing Events. That particular feature helps the developer understand the root cause of a defect. So you can locate the starting point of the defect and figure out exactly how it is being exploited. So contributing Events lets you create that kind of a workflow. 

We also need a tool that works in an environment that isn't dependent on the built environment. You point it to a folder. Then the tool picks it up, runs the scan, and gives you the report. That feature is available in Coverity. So you don't have to rely upon build artifacts or developer artifacts. So these are the two key features we use daily, and we've gotten good results. 

Coverity's UI is the one thing that needs improvement. Technically speaking, it's doing an outstanding job otherwise. Also, they could reduce their executable size. Right now, the Coverity executable is around 1.2GB to download. If they can reduce it to approximately 600 or 700MB, that would be great. If they decrease the executable, it will be much easier to work in an environment like Docker.

I've been using it for the past two years.

This product has been in the industry for more than 30 years, so it's pretty robust.

Coverity has a decent SLA. The moment you purchase the tool, you also get an SLA agreement with all the email support. They have email support, call support, as well as WebEx and Zoom sessions on demand. Of course, that depends on the nature of the technical issue. If it's simple, it can be resolved with a couple of email exchanges, but if it really needs some attention, they're happy to get on a call. They've even delivered some custom patches as well. 

I used CodeSonar a few years back. Both tools have their advantages. In any static analysis tool, the first stage is the instrumentation of the source code. It'll try to capture the skeleton of your source code. So when I compare them based on the first phase alone, Coverity is far better than CodeSonar. 

They both use a similar technique, but CodeSonar uses up way more storage resources. For example, to scan a 1GB code base, CodeSonar generates more than 5GB of instrumented files for every 1GB of code base. In total, that is 6GB. Coverity generates 500MB extra on top of 1GB, so that equals 1.5GB all in. That's a huge difference. CodeStar would eat up my disc space and hardware resources when I used it, whereas Coverity is minimal. 

In terms of checkers, both CodeSonar and Coverity cover a good length and breadth, especially for C and C++ programming languages. But CodeSonar focuses only on four languages—C, C++, Java, and C#—only four programming languages, whereas Coverity supports more than 20-plus programming languages.

Also, the two are comparable with respect to their plugin offerings, but there are crucial differences. For example, CodeSonar only focuses on well-known integrations, like Jenkins and JIRA, but you cannot expect all customers to use the same tools. Coverity supports almost all CI/CD tools, including Jenkins and Bamboo. It also integrates with service providers like Azure DevOps Pipelines, AWS CodePipelines that CodeSonar hasn't added yet. The plugins are available in the marketplace, and you don't have to pay extra. You just have to download it from the marketplace, hook the plugin in your pipeline, and ready to use kind of approach. So these are some of the major use cases, three major use cases I would say when you compare apples to apples with CodeSonar and Coverity.

Setting up Coverity is pretty simple. It comes with a normal executable. You just double click, follow the wizard, and complete the setup. It also have on screen instructions as well, which makes it pretty easy and cool. Deployment is a much broader question. It depends on how many projects you are trying to scan using Coverity and whether you are integrating this static analysis solution with your CI/CD setup, ID, bug tracking, etc. That all factors in to the total deployment time. So if we're talking about overall deployment, including bug tracking, integration, email notification, CI/CD integration, and everything, it took us 15 to 20 days to onboard 600 projects with 20 users, including all integration.

We don't have a lot of maintenance. There is a major release every quarter, and we get information on new upgrades, patches, and things like that. And we do have the option to not upgrade. The maintenance is mostly covered by the vendor itself, meaning they deliver the patches and upgrades on time. So I don't see that as a hurdle right now. It's been taken care of.

I'm not sure about the licensing. My commercial team deals with that.

I rate Coverity nine out of 10. It's a good choice. If you plan to use Coverity, you should read through the manual to really understand its settings. You have to tune the Coverity engine to get the best research and scalability out of it. A Coverity recently added some smart features that automatically compute the hardware requirements in your current machine. It automatically scales up. For example, it can detect how much multi-core CPU power it needs to run an analysis and how much memory is required, so it makes resources available for other applications running on the same machine. That intelligence has been built on. So initially, I recommend going over the fundamentals and fine-tuning it based on one's own requirements.

We use the on-premise deployment model of this solution. Our primary use case of this solution is for auditing. 

The security analysis features are the most valuable features of this solution. 

The quality of the code needs improvement. They should develop a better code. 

The interface, efficiency, and the performance also need improvement as well as the languages that it offers. It should have more language options.

The user interface is not user-friendly.

It is stable. 

We have 30 users licensed for this solution. We use it when we need it. 

Their technical support isn't so good. That needs improvement. They don't address the problems I bring up. It's not a priority for them. 

We previously used an open-source solution before Coverity. 

The initial setup was easy. The solution is complex to use but not complex to deploy. 

We deployed the solution ourselves. 

Licensing is on a yearly basis. 

I would recommend this solution depending on the language you're using, Java and C++.

I would rate it a five out of ten. Not a ten because it's not efficient for the language we use. 

I am a consultant and I work to bring solutions to different companies. Static code analysis is one of the things that I assist people with, and Coverity is one of the tools that I use for doing that.

I worked with Coverity when doing a couple of different PoCs. For these, I get a few different teams of developers together and we want to decide what makes the most sense for each team as far as scanning technologies. So, part of that is what languages are supported, part of that is how extensible it is, and part of that extensibility is do the developers have time to actually create custom roles?

We also want to know things like what the professional are services like, and do people typically need many hours of professional services to get the system spun up. Other factors include whether it deployed on-premises or in the cloud, and also, which of those environments it can operate with.

One of the things is there's not really a shining star out of all of these tools. SaaS tools have been getting more mature in the past decade, particularly in how fast they run, but also in the results they get. Of course, framework and language additions that increase the capability with results are considered.

The most valuable feature is that there were not a whole lot of false positives, at least on the codebases that I looked at.

It should be easier to specify your own validation routines and sanitation routines.

For example, if you have data coming into the application, perhaps something really simple like it's getting a parameter from a web page that is your username when you go to a website to login, and then ultimately that's being consumed by something, the data goes through some business logic and then, let's say, it enters that username into a database. 

Well, what if I say my username is JavaScript calling alert hello. Now I've just entered JavaScript code as my username and you should be able to sanitize that pretty easily with a number of different techniques to remove the actual executable code from what they entered on the login page. However, once you do that, you want the program to understand that you are doing it and then remove what looks like a true positive at first glance because, in fact, the data being consumed in the SQL exec statement is not unsanitized. It's not just coming from the web.

Likewise, let's say you log in, and then it says, "Hello" Such and such. You can inject JavaScript code there and have it be executed when it says hello. So basically the ability to say that this validates and then also above and beyond that, this validates data coming from any GET parameter on the web. You should be able to specify a particular routine validates all of that, or this particular routine validates anytime we read data from a database, maybe an untrusted database.

So, if I reach for that data eight times and I say, "Hey," this validates it once, I also get the option to say it validates it the other seven times, or I could just say it's a universal validator. Obviously, a God validator so to speak is not a good practice because you're sure to miss some edge cases, but to have one routine validate three or four different occurrences is not rare and is often not a bad practice.

Another thing that Coverity needs to implement or improve is a graphical way to display the data. If you can see an actual graphical view of the data coming in, then it would be very useful. Let's say, the first node would be GET parameter from a webpage, and then it would be an arrow to another method like validate user ID, and then another method of GET data about the user. Next, that goes into the database, and so forth. When that's graphically displayed, then it is helpful for developers because they can better grab onto it.

The speed of Coverity can be improved, although that is true for any similar product.

It never crashed so stability has not been an issue.

I have never used it for more than four relatively small to medium-sized projects at a time, so I've never needed to scale it.

I have dealt with sales engineering, rather than technical support. They would sometimes provide a liaison to tech support if they didn't know the answer, but really, they guided us through the proof of concept and they knew that they were under a competitive evaluation against the other tools. They were able to resolve any issues that we came across and got us up and running fairly quickly, as far as I recall.

Coverity is on the good side when it comes to setting it up. I think that it is pretty straightforward to get up and running.

We implement Coverity on our own, with guidance from Coverity.

The price is competitive with other solutions.

In addition to Coverity, I have experience with Checkmarx, Fortify, Veracode, and HCL AppScan, which was previously known as IBM AppScan.

Checkmarx is probably the most extensible and customizable of these products, and you're able to use the C# language to do so, which a lot of developers are familiar with.

HCL AppScan is another tool that has customization capabilities. They are not as powerful but they are easier to implement because you don't need to write any code.

I cannot give an endorsement for any particular one. They all have their merits and it just depends on the requirements. Generally, however, all of these tools are getting better.

My advice for anybody who is considering this product is to first look around your organization to see if it has already been implemented in another group. If you're a big organization then Coverity or a similar tool may already be in use. In cases like this, I would say that it is best to adopt the same tool because your organization has already gone down that path and there are no huge differences in the capabilities of these tools. Some of them do it in different ways and some do things that others don't, but you won't have the initial bump of the learning curve and you can leverage their experience.

I would rate this solution a seven out of ten.

I like Coverity's capability to scan codes once we push it. We don't need more time to review our colleagues' codes. Its UI is pretty straightforward. 

The product should include more customization options. The analytics is not as deep as compared to SonarQube. 

I have been using the product for one month. 

I would rate Coverity's stability a ten out of ten. 

I would rate the product's scalability an eight out of ten. My company has three users for the tool. 

I would rate the tool's setup a seven out of ten. The deployment gets completed in a couple of minutes. 

I would rate the tool's pricing a one out of ten. 

Coverity's documentation is pretty straightforward and I would rate it a seven out of ten. The solution is cheap and provides us with a dedicated server. 

The product has deeper scanning capabilities. 

The tool needs to improve its reporting. 

I have been working with the product for one and a half years. 

The product's stability is good. 

The product is scalable since it can integrate CI/CD tools. My company has 10 users for the product. 

The solution's support is fast. 

Positive

The solution's setup is easy. 

The tool's price is somewhere in the middle. It's neither cheap nor expensive. I would rate the pricing a five out of ten. 

I would rate the solution a ten out of ten. 

We use this solution to scan our products. We've integrated with our build system and it automatically completes the scanning.

The ability to scan code gives us details of existing and potential vulnerabilities. What really matters for us is to ensure that we are able to catch vulnerabilities ahead of time.

When I put my code into Coverity for scanning, the code information of the product is in the system. The solution could be improved by providing a SBOM, a software bill of material. They could also integrate a software composition analysis scan. This would make my job a bit easier.

There is scope for Coverity to look beyond static analysis. Most of people that I have spoken to use Coverity from a pure static analysis perspective. However, we also need to be able to view dynamic pages and APIs using dynamic scanning and SES scans. Currently we would need to use another solution to be able to do this. 

I have been using this solution for 10 years.

This is a stable solution.

This is a scalable solution.

From a support perspective, they are pretty responsive. I would rate them a five out of five. 

The the last ten years, our company has derived value from using this solution. We continuously evaluate our tech stack and if a better solution came along, we would consider it if it provided more value. 

This is a pretty expensive solution. The overall value of the solution could be improved if the price was reduced. Licensing is done on an annual basis. 

There are other new tools like Veracode, Java Icon and Javascript which are better than Coverity when it comes to visualization. Their cost is significantly lower compared to Synopsys. 

Coverity is really good with CC+ and legacy technologies. However, there are other products that are probably as good or even better than Coverity when it comes to Java or cloud applications. 

If someone were to ask me what tool I would recommend, my answer would depend on what technology they're using and what their use case is. My advice would be based on how they're going to use the product and what they're expecting from the tool.

I would rate this solution an eight out of ten. 

We use Coverity during the software integration phase. We have a lot of components so we use Coverity to build the components, analyze and publish the data into sonar server and that's our work.

Depending on our product's needs, we defined the rule set to check and improve the source code.

The features I find most valuable is that our entire company can publish the analysis results into our central space. That allows us to see the latest quality of all components on the sonar web page.

My personal opinion is that the webpage of the last version of Coverity is not very easy to use. They've made some unnecessary changes and now I can't see all the analysis results or my status from when we started using the solution up to now. Because we have many components on the integration field, it is sometimes hard to find files of one specific component because we use relative path. When I look at the components, they all look very similar. But that is just my personal opinion.

I would also like to see a more user-friendly user interface and configuration. I can see the menu on the left but it's a little different from the other tools that I use, but this is perhaps only a personal thing. 

Coverity is a very stable solution.

I believe the solution is scalable. Sometimes I want to put one component in a certain project, and I need to find what's the best way for us. We have a lot of users using Coverity and we will adapt it into our program. 

Most of the time I just do some research myself and Google their webpage to see how I can find a solution for my problem. The program has a tools team to help find the solutions. 

My personal business used other tools that offered sonar language tracking. We used a mix of programs with specific options and some standard gcc options. But last year our team preferred to use more visual tools to follow the whole company's policy. That is why we chose Coverity.

We have an administrator for the deployment, so I am only a user. I just added a few projects and streams, and use the data extracted from the compilation, and run the analysis. The setup did take a long time, however.

We implement through an in-house tools team.

I don't care it so much.

For the setup, it's better to adapt the solution from the mature projects.

Don't care so much the pricing and licensing being the end user.

Before choosing, we tried to use gcc compiler options, i.e. 

EXT_GCOV_FLAGS='-fprofile-arcs -ftest-coverage'
EXT_GCOV_LDFLAGS=-fprofile-arcs
EXT_CC_FLAGS=-fdiagnostics-show-option
GCOV_LIB=-lgcov

I will suggest that when they use the program for a new project, they should just copy the data from a mature solution to the new project because the setup really takes a long time. We spent a lot of time to set Coverity up because I thought of creating the project in the Coverity server and use Coverity for the sonar part properly. But it took a long time. I will give the solution a 7.5 rating out of ten. When we officially use all the data, it will accumulate more experiences and then we will have different opinions.