Coverity Reviews

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. 

We are using Coverity for Android, cluster programs, and infotainment.

Coverity's setup takes a long time. Coverity gives advisory and deviation features, which are some of the parts I liked.

SCM integration is very poor in Coverity. The IDR file is not portable. After the analysis, it generates an IDR file. It cannot be ported from the machine since it is machine specific. Also, the component mapping has to be done manually. We cannot upload in one shot through automation or an Excel sheet. That is also a drawback.

In terms of the additional features that the solution should possess, I would say that it should have very good and sound features for Android-related stuff and embedded features should be supported. Also, infotainment programs for people who are using HMI should be supported very well.

I have been using Coverity for more than one year. In my company, we use the tool. Also, we go to the vendor for support. I am using Coverity 2022.

Speaking about stability, I would say that product-wise, there is no such complaint. There are no alarming complaints. However, some minor things we have to fix, use and tune it. With the newer versions, the only problem is if any new version or any new tool or new plugin comes to our infotainment program, then even with vendor support, we won't get a solution since maybe the tool is not supported or because there is something else that has to be looked into. We are facing problems due to such cases. Otherwise, it's fine, so it is good enough for an existing tool and program.

The product is scalable if provided if the tool is supported well, and if new features are incorporated parallelly, then definitely it's scalable.

To speak exactly about the number of users is difficult, but above 300 people in my company use the solution.

There are four or five members out there who manage Coverity's administration from a project point of view.

My opinion on support depends on what kind of support my company has adopted. I need to check. I don't know what company support they have provided. If they have taken golden support, support will come like that. In that way, I don't want to comment on that.

Initially, I worked with Klocwork in my previous company.

Regarding Klocwork, if you can provide me with its information, then we would definitely like to explore it.

Initial setup for the infotainment program is not easy. This is because the template, specifically code template files, have to be generated, and that itself takes time since they talk to the vendor and they get the template files. We are using the same template file for most of the programs. It is not fixed that this program has to use this template file, so it is not like that. since it has to be fine-tuned.

For a few programs, like cluster programs, it takes only half a day or a day to get the setup done since everything is ready. But for infotainment, it sometimes takes three to four days, and issues keep coming in for the new enablement. Hence, it may take even three weeks to one month sometimes.

Coverity’s price is on the higher side. It should be lower. It's definitely priced on the higher side, and in that sense, I will definitely give a big alert stating that it is on the higher side of the price.

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 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.