There should be additional IDE support. IDE stands for an integrated development environment, like Eclipse. It would be helpful if we could enhance the integration between Coverity and IDEs. Additionally, it would be beneficial to increase the support for different IDEs.

In future releases, there should be a slightly more user-friendly reporting interface.

We actually specified several checkers, but we found some checkers had a higher false positive rate. I think this is a problem. Because we have to waste some time is really the issue because the issue is not an issue. I mean, the tool pauses or an issue, but the same issue is the filter now.Some check checkers cannot

find some issues, but sometimes they find issues that are not relevant, right, that are not really issues.

Some customisation mechanism can be added in the next release so that we can define our Checker. The Modelling feature provided by Coverity helps in finding more information for potential issues but it is not mature enough, it should be mature. The fast testing feature for security testing campaign can be added as well. So if you correctly integrate it with the training team, maybe you can help us to find more potential issues.

The product must allow users to customize the issues they want to identify. Some of the issues reported by the tool were not that critical. We had a long list of low-priority issues that were piling up. It would be great if we could customize the rules to focus on critical issues.

The sales strategy needs to improve. First of all, Coverity will give you a low price; then, one year later, they will raise the price. So it becomes expensive later.

Moreover, Coverity is not doing good in terms of some specific features. For example, in the for loop, they can only check the point of the plus statement and cannot handle the sub-encryption. It can only handle the increase and not the decreased logic. So they will miss critical issues in some conditions.

In future releases, the price and policy could be improved, and also the script for the loop.

The solution could use more rules. For example, if I have a lot of rules in many languages, it helps my company as having access to more rules works for us.

We'd like a bit more integration.

We use GitHub and Gitflow, and Coverity does not fit with Gitflow. I have to create a screen for our branches, and it's a pain for developers. It has been difficult to integrate Coverity with our system.

In the next release, I would like to have the ability to easily add screens to branches myself as a developer.

Coverity takes a lot of time to dereference null pointers. The product's price is one of its shortcomings, where improvements are required. In general, the price of the product should be kept low.

In the future, Coverity should provide more flexibility.

We've found that there is a quite high false positive rate. It's a problem because we end up wasting time on something that's not an issue. The tracker reports too many issues that are not relevant. I'd like to see some kind of customization mechanism in the future. 

The level of vulnerability that this solution covers could be improved compared to other open source tools. The UI could also be improved. We also cannot directly report the vulnerability. We need to add filters to projects and only then can we download reports. 

The solution is a bit complex to use in comparison to other products that have many plugins.

More features could be included for finding bugs and analyzing code. For example, more information could be included to explain errors such as memory leaks. 

The product could be enhanced by providing video troubleshooting guides, making issue resolution more accessible. Troubleshooting without visual guides can be time-consuming.

Triage history has many bugs and needs to be improved. There could be a subsection. The solution could provide a graphical representation like other tools.

We have OS 2021, which is not the latest one. It should be updated regularly.

Sometimes, vulnerabilities are not identified even after setting up the automated scanning rules. They should include a feature combining automated scanning tools with manual code reviews for better output.

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. 

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 would like to see integration with popular IDEs, such as Eclipse. If Coverity were available as a plugin then developers could use it to find security issues while they are coding because right now, as we are using Coverity, it is a reactive way of finding vulnerabilities. We need to find these kinds of problems during the coding phase, rather than waiting for the code to be analyzed after it is written.

Coverity could improve the ease of use. Sometimes things become difficult and you need to follow the guides from the website but the guides could be better.

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

The tool needs to improve its reporting. 

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.

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.

Sometimes it's a bit hard to figure out how to use the product’s UI.

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.

The solution's user interface and quality gate could be improved.

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

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. 

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. 

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. 

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

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

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.

They could improve the usability. For example, how you set things up, even though it's straightforward, it could be still be easier.