SonarQube Reviews

It prevents some vulnerabilities in the production environment.

I like that it covers most programming languages for source code review.

I also like the procedures that are already built-in that cover most of the items that already exist.

SonarQube does not cover BPM programming language. It only covers the Java layer from BPM WebMethods. When we were faced with this issue with one of your applications, we found that we were not able to scan the BPM code for configurations generated from the WebMethod.

The BPM language is important and should be considered in SonarQube.

It utilizes a lot of resources from the servers. I think this issue should be resolved because it takes approx 20% of the CPU utilization.

Reporting related to SonarQube only exists in the enterprise edition, and not in the Community Edition.

There are no limitations in the lines of code with the Community Edition, but with the Enterprise Version, there are limitations related to the lines of code.

I don't understand why you can use an infinite line code amount with the Community Edition and the Enterprise Edition is limited.

We have been dealing with SonarQube for more than one year.

It is stable in the system environment processes.

We haven't used it with the microservices or containers to check the scalability. We have used it on a Windows Server or Linux Server.

We contacted technical support about the BPM and WebMethod programming language. They supported us with a fast response and provided us with a solution that was not covered on SonarQube.

We only use SonarQube with SonarScanner.

The initial setup is simple and straightforward.

I am a consultant and my team completed the system server.

I requested this license for one million lines of code and they accepted this.

I don't know what was already paid.

We evaluated Micro Focus Fortify. From a cost perspective, we selected SonarQube. Now we are using the enterprise license as well. 

We are telecommunication customers, who have purchased a license. We are the largest telecommunications company in Saudi Arabia.

I would rate SonarQube an eight out of ten.

We use it to check the code quality, and the code review to find out the vulnerabilities about the central codes like simplifications and codes. We also use it for security management.

The most valuable feature is the security hotspot feature that identifies where your code is prone to have security issues.

It also gives you a very good highlight of what's changed, and what has to be changed in the future.

Apart from that, there are many other good features as it's a code analytics platform. It also has a dashboard reporting feature, which is very good. I also like the ease of its integration with Jenkins.

Another valuable feature is the time snapshot that it provides for the code. It provides the code quality, the lagging, and the training features like what already has gone wrong and what is likely to go wrong. It's a very good feature for a project to have a dashboard where the users can find everything about their project at a single glance.

There are various standards that are followed. Awareness is a must.

Product awareness is something that I would recommend. If the users are not aware of how to use the product, they won't understand the features.

I have been using SonarQube for three years. 

It is quite stable. There are no kind of issues that we face on SonarQube. It's just about the awareness where the users are not aware of a feature and that's where we need to jump in and explain some of the features about how it works.

It's definitely easy to scale. 

We do contact them based on the project team requirement. We contact them if they have to set up any specific kind of portfolio application and such application et cetera, internal.

Their support is good. They respond quickly. The response time is very good. They answer the queries within 24 to 48 hours. That's a plus for them. It's a very costly product, so we use the enterprise-level product. It does consume a lot of license cost for that.

We used Fortify, it is also another tool for static code analysis. The security team used to use that, but not in our team because ours was a newly assembled team for the work. 

The initial setup is simple. It's basically an orchestration platform on which I manage around 400 SonarQube incentives.

It's a mass production environment. I'm currently managing around 400 plus teams who are using the product. We are trying to migrate it onto Kubernetes.

The setup takes around five to ten minutes as I have created automation. 

It requires maintenance on the platform side, but not on the SonarQube side. Because there is a DB cleanup automatically inbuilt in Sonar, it does not require much to maintain within SonarQube itself.

It eats up a lot of memory. For a stack it's around 2.5GB. We use it on a daily basis. 

Everything is included in the standard licensing. 

Awareness about how to use the product is important. It's a very good product for developers because it gives you timely notifications about where the tool has gone wrong or what could go wrong in the future. That's popular for developers. It's very good for the stats about the product for architects

The metrics are how the budgeting should be done et cetera. These are the things that they can find out from the dashboard based on the lines of codes. 

In the next release, I would like to have notifications because now, it is a bit difficult. I think that's a feature which we could add there and it would benefit the users as well. For every full request, they should be able to see their bugs or vulnerability directly on the surface.

I would rate it an eight out of ten. 

I work for a government agency and we use this tool. It is lightweight and very cost effective as compared to IBM AppScan, but I wouldn't say it's a very good tool for vulnerability assessment. The dashboard is neat and easy to operate and the information on the dashboard makes it easy for the developers to work on. You can have it automated and set up for you to have an automated process every time the code is checked in. 

It definitely helped our organization in hardening the software, the application itself. This is a part of our process now.

The most valuable features are the dashboard reports and the ease of integrating it with Jenkins. 

Although it has Sonar built into it, it is still lacking. Customization features of identifying a particular attack still need to be worked on. To give you an example: if we want to scan and do a false positive analysis, those types of features are missing. If we want to rescan something from a particular point that is a feature that is also missing. It’s in our queue. That will hopefully save a lot of time.

This solution is very stable.

It supports around 25 plus languages.

The technical support is very good. When a product is good, we don't use them as regularly.

No, not that I am aware of.

Compared to other tools, the initial setup was straightforward. The deployment of the tool didn't take long at all. You need to take intrinsic care but setting up this tool is pretty easy. One can do it in a couple of hours. The dashboard is really neat and easy to operate. It gives a lot of information that makes it very easy for the developers. We haven't ever used more than one resource for operations.

We have this implemented in CSAD pipeline as one of the tools for finding bugs in source code. This kind of tool has the capabilities of debugging abnormalities or finding abnormalities. We use it the same as any other static one level detail, and with a few other static tools like AppScan and Checkmarx.

SonarQube is a very good tool. It is lightweight and very cost effective as compared to IBM AppScan. The dashboard is really neat and easy to operate. It gives a lot of information that makes it very easy for the developers. You can get it set up as an automated process every time the code is checked in. I would say, however, that it is not a vulnerability assessment tool. The dev and security team use this solution very closely. Fifteen to twenty people in total use it.

I would rate this solution an eight out of ten.

The product needs to integrate other security tools for security scanning. 

I have been using the product for a year. 

SonarQube is scalable. My company has 50 users. 

I rate SonarQube an eight out of ten. 

SonarQube is a code-scanning tool that ensures people follow the right coding standard. It detects any memory leaks or unwanted functions that have been written so developers can optimize the code for better performance. We don't know too much about how our customers use SonarQube because we just set it up for them. We show them how the reporting works and what to do to fix common issues. 

SonarQube is one of the more popular solutions because it supports 29 languages.

SonarQube supports most database languages, like SQL queries, PL/SQL, etc., but some newer programming languages are not there. For example, it's missing some more popular languages like Apache Groovy. I would like to see some support for scanning these new popular languages.

I would also like SonarQube to be able to write custom scanning rules. More documentation would be helpful as well because some of our guys were struggling with the customization script. 

I've been using SonarQube for the past eight years or so. I am a DevOps consultant who helps the end-users set up their environments. My clients operate in various industries, including the service industry. 

SonarQube takes five to 10 minutes to install, and I train people on this technology, so I install it for them and teach them how to use it. On Linux, it maybe takes another five or 10 minutes, but it is straightforward.

We first try it out with a limited number of users, so four or five users will run it, but the report is shared with multiple users. The report generated will go to thousands of users. You run the report from the DevOps point of view, then share it with everyone.

I'm involved in the price discussions, so I'm unaware of the cost. However, I don't see any other competitors in the same space. There are one or two, but they're not popular. SonarQube is free for one user, so people can explore it, but if they need enterprise support, they can buy licenses, and we can go forward.

SonarQube is the only code scanning software I've tried, but I've also seen Nexus Scanner. However, it's not for binary scanning and so forth. It won't scan your source code. It's just an artifact scanner. 

I rate SonarQube eight out of 10. I always recommend SonarQube because it is also available in an open-source version, so people can understand the power of this tool and how it can help in an IT setting. 

Our primary use case of SonarQube is getting feedback on code. We are using Spring Boot and Java 8. We are also using SonarLint, which is an Eclipse IDE plugin, to detect vulnerabilities during development. Once the developer finishes the code and commits the code into the Bitbucket code repository, the continuous integration pipeline will automatically run using Jenkins. As part of this pipeline, there is a build unit test and a SonarQube scan. All the parameters are configured as per project requirements, and the SonarQube scan will run immediately once the developer commits the code to the repository. The advantage of this is that we can see immediate feedback: how many vulnerabilities there are, what the code quality is, the code quality metrics, and if there are any issues with the changes that we made. Since the feedback is immediate, the developer can rectify it immediately and can further communicate changes. This helps us with product quality and having less vulnerabilities in the early stages of development. 

This solution is deployed on-premise. 

One of the most valuable features of SonarQube is its ability to detect code quality during development. There are rules that define various technologies—Java, C#, Python, everything—and these rules declare the coding standards and code quality. With SonarQube, everything is detectable during the time of development and continuous integration, which is an advantage. SonarQube also has a Quality Gate, where the code should reach 85%. Below that, the code cannot be promoted to a further environment, it should be in a development environment only. So the checks are there, and SonarQube will provide that increase. It also provides suggestions on how the code can be fixed and methods of going about this, without allowing hackers to exploit the code. 

Another valuable feature is that it is tightly integrated with third-party tools. For example, we can see the SonarQube metrics in Bitbucket, the code repository. Once I raise the full request, the developer, team lead, or even the delivery lead can see the code quality metrics of the deliverable so that they can make a decision. SonarQube will also cover all of the top OWASP vulnerabilities, however it doesn't have penetration testing or hacker testing. We use other tools, like Checkmarx, to do penetration testing from the outside. 

SonarQube could be improved with more dynamic testing—basically, now, it's a static code analysis scan. For example, when the developer writes the code and does the corresponding unit test, he can cover functional and non-functional. So the SonarQube could be improved by helping to execute unit tests and test dynamically, using various parameters, and to help detect any vulnerabilities. Currently, it'll just give the test case and say whether it passes or fails—it won't give you any other input or dynamic testing. They could use artificial intelligence to build a feature that would help developers identify and fix issues in the early stages, which would help us deliver the product and reduce costs. 

Another area with room for improvement is in regard to automating things, since the process currently needs to be done manually.

Aside from other helpful features, the most important thing that SonarQube needs to do—the key feature—is to detect security vulnerabilities. The rest of the other features are helpful to the developer and the team to deliver the product faster, but security is a mandatory feature. 

As for additional features, SonarQube covers most of the languages, but there is still room for improvement covering the latest version of the tech stack—for example, Java 13. They're still improving, and they're focusing on SonarCloud nowadays. Currently, we aren't using all the top quality features of SonarCloud. I also think it would be helpful if SonarQube could integrate with Jira, a work management tool, or other communication tools, like Skype or Microsoft Teams, so that a bot could report directly to the developer. 

I have been using SonarQube for the past three years. 

The stability and performance of SonarQube are good. We use it on a daily basis, as part of our code development. 

As far as maintenance, it mainly happens when the product is being developed. There may be some features which can be enhanced, based on customer feedback and the tech stack, such as how we can improve performance of have a deployment with zero downtime. There are so many technologies coming, so many things happening, and there is always room for code improvements and the product we develop. Our top considerations are quality and security, which are being improved in a continuous process. There are many new features and enhancements coming in—for example, if you want to upgrade from the Java 6 version, then you can upgrade the tech stack, which will reduce the number of lines of code and improve performance. 

This solution is easy to scale. The instances in which we are deploying it are easy to scale because we are using it in production. We aren't supposed to deploy as part of the development, but the scalability feature is there because we are using Ansible, Kubernetes, and Docker. 

In our organization, there are currently around 25,000 people working with SonarQube. 

We also use Checkmarx and Snyk. One of the main differences between them and SonarQube is that they have dynamic testing and analysis, rather than static analysis. 

The initial setup wasn't a complex process. It was straightforward, and I had no issues. The deployment happened automatically and the pipeline was complete in three minutes. It depends on the scale of the project, the number of code repositories, the number of modules you are deploying, and all that. I would say deployment should take five minutes, maximum. 

We implemented this solution through an in-house team. Everything happens internally and we have our own internal tools, so there are no third-parties involved in development. 

I'm not too aware of the pricing because a different team covers that, but SonarQube has been on the market for a very long time, so I would guess the pricing would be decent. 

I rate SonarQube an eight out of ten. 

To those looking to implement SonarQube, I would advise you not to run it manually—integrate it with tools like Bitbucket and Jenkins, and make it automatic. If you change one line of code, the SonarQube should run automatically and give you the report. Don't go and run it manually and check the reports and all—it should run automatically to the entire code base, not to your particular module. So you need to configure that, as well as your project requirements and what code quality metrics will be achievable—like 85% or 95%—because you want code quality for a better product, without loopholes. You need to configure these things before starting to work with SonarQube. 

Our primary use case is to analyze source code for software bugs, technical debt, vulnerabilities, and test coverage. It provides an automated gated procedure to ensure that engineers are able to deliver great, secure code to production. 

We plug this process into our process right from the start enabling the IDE integrations so that engineers can scan their code before submission. Following on from that we run the scans on every change that has been submitted for review. 

This way we ensure that no core/fundamental issues are added to our codebases. 

It has helped many of the organizations that I have worked at to improve overall security, quality, and test confidence within the codebases. It also provides this in a speed efficient way. Engineers now feel much more proud of their solution as they gain confidence from these scans and their results. 

Engineers have also learned from the results and have improved themselves as engineers. This will help them with their careers. 

We are also able to get reports on our suite and generate a quality rating for ourselves utilizing this data and more. 

By far the quality gate controls. Without this, there would be no way to really utilize the power of this tool. We are able to automatically ensure that no code is delivered to production when it contains severe bugs or vulnerabilities. 

The tight integration to source control also helps us to keep the engineers in the loop with any follow-up actions for issues reported. 

Finally, the historical trend analysis gives us great insight into how we are improving based on our decisions, which are now driven by clear data.

It should keep up with newer technologies. As this is primarily open-source, it does require updates from the community. As such, there is sometimes a delay for new technologies to be covered by this too. 

Particularly around the languages that the webpages state they support. The big benefit of Sonar is that it handles so many different languages, problems, and static analysis in one place. 

When that one place has a low coverage for the most basic rules (OWASP top 10 for example) it starts to lose its value add. 

I have been using SonarQube for five years.

Good, I have not really had many issues with it. No major ones either. 

It all depends on where/how you are hosting it. The tool itself scales well. 

I have used Checkmarx and also tried a demo of Veracode. 

Checkmarx was far too heavy-handed and only handled security concerns for a VERY large price tag. 

Veracode is very good, however, the price vs a free solution was a deciding factor in many cases. 

It's very straightforward for a SaaS setup. 

For a self-hosted setup, it is documented well and fairly easy. 

We implemented in-house.

SonarQube will incur hosting costs. There are SaaS options available at competitive prices too. 

Self-hosting SonarQube is subject to its open-source licenses documented on their website. 

We also evaluated Checkmarx, Veracode and open source solutions specific to each programming language. 

Security analysis is a MUST. 

We're collecting code quality metrics.

We have the software metrics that SonarQube gives us, which is something we did not have before. This helps us work towards aiming coding standards to empower us to move in the direction of better code quality. SonarQube provides targets and metrics for that.

I like the dashboard it shows by default, where you can see things at a glance. At the same time, you can also drill way down and see a lot of stuff about your code, like complexity metrics, and things like that. It gives you a nice dashboard where you can just look at a birds-eye view.

We've been using the Community Edition, which means that we get to use it at our leisure, and they're kind enough to literally give it to us. However, it takes a fair amount of effort to figure out how to get everything up and running. Since we didn't go with the professional paid version, we're not entitled to support. Of course, that could be self-correcting if we were to make the step to buy into this and really use it. Then their technical support would be available to us to make strides for using it better.

On the other hand, there are published books available. However, the one problem I ran into is they were a little bit out of date. They're still very helpful, but we had to kind of translate from the previous version that was covered in the published books to what's actually available now.

An improvement I would like to see would be on the part of the authors to come out with a new edition or revision that covers some of the newer features of SonarQube and newer configurations. I'd buy a copy.

In terms of additional features, it's actually a very complete solution from what we have seen. Again, I would like the authors to revise their books. I think even ordinary people that are using the licensed model with direct support could walk through some different use cases, just from having been around the block a few times. There are enough things that the software does that this could be very beneficial. Even beyond the technical issues of installation, there are further use cases that could be helpful. For instance, how to get the big bang from the buck out of it.

We use C++ and a lot of Python. Another group in our company is using Java. SonarQube is more directly suited for Java, being almost built into it, whereas C++ requires some extensions. The Java group is using a newer version. We were kind of hoping to piggyback on theirs but SonarQube did not create newer versions of the C++ interfaces as open source. It's starts costing money so we haven't crossed that threshold yet. We haven't established a clear path.

I think if you're going to get the paid model, I get the impression it would do pretty much everything you need as far as metrics go.

A colleague of mine did some work looking at some plugins for Visual Studio and things like that, but they weren't going to work out, so we did take a look at some other options where they could have everything done on the desktop. Our solution in place now requires an infrastructure where it doesn't look at your code, but rather the code that you last checked in, which takes some levels of complexity that we've kind of built-in anyway. It's a little less intuitive how it works to the casual observer. It's set up now to where they don't have to know how it works, they can just go to the web interface and see it.

There are about eight programmers in our section of the solution. So we're kind of a smaller shop compared to some, but larger than many.

Certainly right now I think SonarQube is being underutilized, just because old habits die hard. If I had any say I would like to change that. We had coding standards in place, but they were written documents, whereas SonarQube takes that to another level and you had to look at the specification to see what you said you were going to do. It also tells you what the industry norms are, and whether or not you're meeting them. We have had some discussions about which we want to do. If we want it to happen automatically or if we want to go look for it again ourselves. I cast my vote in the automatic way because the research has already been done by the SonarQube community to come up with these roles, rules, coding standards, etc.

It wasn't done in a vacuum. The agile community has been beating on issues like this for a long time, and they're getting to a point that it's becoming a self-sustaining method.

They do have a lot of information on their website for the parts that they're offering free. We don't have licensing but there is a lot of information, it's just a matter of digging for it and you have to infer a few things. With the proper amount of agony we've managed to get there. There are some subtleties as far as configuration parameters. It does it one way, but we'd really like to do it a different way. Finding that magic incantation to flip that switch is not always in bold print so to speak.

Even for the freebie community which we're in, they haven't held back information. The information is out there to do some amazing stuff with it, but you've got to get your shovel and go dig it up.

We do have some other licensed software and when you look for information on their product, all roads lead to them and when you get there, you log in with your account that costs tens of thousands of dollars. SonarQube isn't like that. They don't hold the information back but you just have to go find it on their website by yourself.

We didn't have a previous solution other than paper systems that we never got in the habit of going back to referring to. We didn't switch, we started fresh.

The initial setup was complex because we were using the Community Edition. We did have some issues with the compatibility of the different components. For example, there is the server itself, but then you can plug in different packages, like the C++ package. We've also experimented a little bit with Python metrics, but unfortunately we don't have a project that's really under that control yet, to really get a feel for how that works.

Configuration issues were pretty complicated, but once we got things up and running, it's been extremely stable, it was kind of maintenance-free, now, although we have a time issue. Of the scans that it does, it could be somewhat time-consuming, so originally some of the developers would say, "Well we want to be able to do that on our desktop." I told them, "I don't think you know what you're asking for, here." But as an alternative, we have it set up with our continuous integration server, which we use in TeamCity by the way. In the middle of the night, it automatically runs a scan for them, while they're in bed at home asleep so their results will be ready the next morning. This way, whatever they have most recently checked in, they can see the results right there. And then it runs in the background so it doesn't matter how long it takes per se, it gets it done by the next time they come in. That's part of what continuous integration does, it does things for you that years ago people would do themselves, and never get around to it.

We spent a couple of weeks getting things figured out. I worked with an apprentice, who was kind of going through the motions.

We chose to use a Red Hat operating system for the base. It's running on a Red Hat 7 server which contributes to the stability from the foundation, then installed the actual SonarQube server on Red Hat. That's when we had the compatibility issues and so on when we started installing the scan engines on top of that. That's when things were not compatible with each other and we had to fall back and figure out why things weren't plugging and playing. However, they did have on their website a sheet that had a little chart that showed the compatibility between the different versions and once we discovered that I was able to see which version can work with which.

We didn't have to change the OS or the SonarQube's service itself, but the C++ extension. The version of the C++ extension we were using was not compatible with the Community Edition we had.

We've had a consultant at one point, not to look specifically at SonarQube, but rather at our firmer development processes as a whole. He's the one that played us towards SonarQube being a reasonable option. In fact, he was the one that helped us in finding the compatibility chart.

It's been mostly me doing the implementation on my own. I haven't been full time on it, but about half of my time is devoted to this. I do take some breaks and write some code and do some refactoring on occasion.

As far as time on SonarQube itself, only about a tenth of a person is devoted to this. It's part of an infrastructure. I have a whole family of virtual machines that do different things: build, test, etc..

We had looked at other code quality systems. We had looked at a number of them. I don't remember them all, but Clockwork was on that list. I think it comes down to picking one and getting used to how it works because they all do mostly the same thing. Some of them focus more on Java, some more on C++. I think Java seems to be the favorite. As far as what they can really do for you, there didn't seem to be any one of them that does ten times what another does. There were some differences, but not no show-stoppers that I recall. I guess the advice would be that one of several tools could do a good job for you, but you still have to manage it and manage the behavior that goes along with it.

I would rate SonarQube as a nine out of ten.

Once you start drilling down through the menus, it tells you a lot of stuff about your code in one view. That's really quite neat. That shows you a view of maintainability. They have a maintainability view that shows bubbles for all the different code modules, and yours is beside the bubble. This represents the amount of "code smells," which is actually kind of a common definition. The bigger the bubble, the more your code smells. This shows where more attention is needed or it's a bubble that's kind of drifting out of control.

I have one graph here where there are probably 50 bubbles. There's one axis that shows technical death, meaning the amount of work that it's going to take to get the smells under control. The other axis is lines of code, which is obviously a very common thing to look at. On this particular graph, there are a whole bunch of bubbles down in the lower-left corner, which means you have a lot of small manageable things. 

If you hover over the bubble, it tells you what module it is. How many lines of code. Technical death and manpower estimate, things like that.