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 primarily use the solution for quality purposes. We also use it for security. That's one subset of quality. However, it's used for more dynamic behavior, such as memory leaks, et cetera. 

They have a good memory-related box and a static order analysis that's very good, especially around leaks.

We were very comfortable with the initial setup.

It is stable.

The cost is very high.

They don't have SonarQube compatibility with the dashboard, which is a big negative. They were actually arrogant for not providing it. We wanted to see all the problems in a single SonarQube dashboard, and we can't do that. They need SonarQube integration. They claim that they have SonarQube integration, yet it is not there.

We'd like it to be faster.

The solution could always use a bit more security. 

I've been using the solution for around 12 years. 

I consider the solution very stable. There are no bugs or glitches and it doesn't crash or freeze. It is reliable. 

That said, when we are doing security analysis on bigger projects, it can be slow. 

To scale, you need more hardware. That way it is scalable. That said, it is already handling quite a big amount. We have a specific problem when analyzing security in a big project. It can get slow. 

I'd rate it four out of five in its ability to scale. 

We have around 200 people using the solution currently. 30 to 40 use it on a daily basis. 

We do not have plans to increase usage based on the cost. We're actually looking for an alternative.

Support is not so good. They're too slow. In contrast, Clockwork has very good support.

Neutral

We've used Clockwork before. However, it has the same issues as this product. They're more for C# and C++.

The solution was very simple to set up. The frontend, backend, and UI are very good and easy to navigate.

I'd rate the initial setup process a four out of five in terms of how easy it was.

It is an expensive solution. 

Their sales team is very arrogant. 

I don't like their licensing mechanism. Everything is on very unfriendly terms. 

There are other tools you can use that are free and open-source. 

In a collaborative environment, they are very tricky. When it comes to looking at the bugs on a web interface, they try to block them. When you discuss it with them, they are quite unfriendly. Once you got stuck into the tool, they know that it's hard to leave due to the history. When you get into a tool, you need the history since the history needs to be built up, and therefore, over time, you have a dependency on the tool.

I'd rate the product a three out of five in terms of affordability.

We're a customer.

I would rate the solution seven out of ten.

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.