Coverity Static Reviews

We are using GK and the latest version for port deployment.

I have been using Coverity for three and a half years.

Coverity is not stable but it is sufficient for our organization's requirements.

Coverity is scalable.

We contacted technical support to help us clean up an issue we had.

If they have a cluster structure, then definitely they should use Coverity. I would rate Coverity a nine out of ten.

We use Coverity for static analysis of our code.

Coverity is far from perfection, and I'm not 100 percent sure it's helping me find what I need to find in my role. We need exactly what we are looking for, i.e. security errors and vulnerabilities. It doesn't seem to be reporting while we are changing our code. So either we are perfect, or the tool is missing something. 

I've been using Coverity for a couple of years.

I haven't had much experience trying to scale up Coverity. Only three people at our company work with it.

I encountered a bug with Coverity, and I opened a ticket. Support provided me with a workaround. So it's working at the moment, or at least it seems to be. They are on par with other tech support in terms of knowledge. However, their style of communication could use some improvement.

Setting up Coverity is highly complex. The upgrade procedure is also pretty tough. We've had trouble with it on at least one occasion. When I went ahead with it, it destroyed the installation. I couldn't go back. So it's challenging to understand from the documentation. It seems like they tried to cover all possible topics in their manuals, so they ended up scratching the surface of everything in the world except for the particular practical items that I needed.

Coverity is very expensive.

I rate Coverity five out of 10, but it's tough for me to judge because we decided to purchase it based on one requirement that no other static analysis tool could satisfy. For that reason, we haven't tried anything else. So, let's make an analogy. Let's say I used Sony TVs my entire life, and someone comes up and says, "Hey, there is a new brand of TVs. What do you think of them? Do you think they are good?" How would I know? By comparison, SonarQube seems to be more feature-rich for a standard programming language, and it works with more continuous integration tools.

We use it in our company during product development.

It provides reports about a lot of potential defects.

Its price can be improved. Price is always an issue with Synopsys.

I have been using Coverity for about three or four years.

It has good stability.

Its scalability is good. 

They are professional and very responsible. They have a local FAE.

It is not straightforward, but it is also not too complex. The learning curve needed for installing Coverity is okay.

It is expensive.

I would recommend this solution if you can afford it. If you have enough budget, it is one of the best solutions right now. There may be other cheaper solutions, but you get what you pay for.

We have been using Coverity for several years. We would not have continued using it if it was not a good solution. We always have some minor questions or improvements for them, and they always give us a relatively fast response.

I would rate Coverity a nine out of ten. Only its price should be improved.

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.

We have a development team and we are using this product for static code analysis.

This product has definitely helped our organization. Based on what I have heard from the development team, they have found a lot of issues before code goes into production.

The most valuable feature is the integration with Jenkins. Jenkins can be used to automatically run it to perform the code analysis.

Integration with GitLab is helpful.

Coverity is too costly, which is why we are trying other tools. Ideally, it would have a user-based license that does not have a restriction in the number of lines of code.

We have been using Coverity for between five and six years.

Coverity is used across our entire organization.

The initial setup in the Windows environment was straightforward. However, for Linux, it has some complexity.

We have a separate team in the company that takes care of deployment. One person is enough for the task

The licensing fees are based on the number of lines of code. We may not need more than five user licenses but with a restriction on the number of lines of code, for a small company the cost will shoot up.

Our license for Coverity has expired and we are in the process of exploring new static code analysis tools. Ideally, we would like to have one that is low-cost.

One of the products that I have downloaded a trial version for is SonarQube. At this point, I have only installed the Windows version but I plan on testing the Linux version, as well.

In summary, this is a helpful product and the feedback that I have heard from the development team is good.

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.

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. 

• Raising the level of code quality, security, and robustness in the codebase
• Tracking and addressing code quality issues.
  

Coverity provides developers with a good, best practice, coding advice, and tracks risks of poor coding quality. Coverity reports have urged developers to improve the quality of their code.

• I like that it gives advice and training on how to resolve the most common quality issues. 
• Links to more details on each issue and the background and risks.
  

• Ability to follow source file s-links into the target location for issuing assignments through GIT.  Our current build environment uses symbolic links into the git repo and Coverity does not follow the link into the actual location of the source file to determine the git author.
• Single API for all interactions. I am not a fan of using both SOAP and REST APIs and Coverity offers a mix of functionality depending on the interface used. I would greatly prefer a full REST API with improved documentation for all actions including issuing assignments, streaming, and project creation.