SonarQube Reviews

Our primary use is for coding best practice management and quality. Aside from that, we also use it for security.

I'm getting involved in moving this solution forward and positioning it in our enterprise so I haven't gotten to the point where we're nailing down the configuration and release controls yet.

SonarQube has not yet had an impact on our organization. In the past, however, I've used it to control the security vulnerabilities and establish standards for API control.

There are two major use cases. One is to integrate it into the developers' workbench so that they can bench check their code against what will be done in the server-based audit version.

I haven't really done a comparative analysis yet.

We're in the process of figuring out how to automate the workflow for QA audit controls on it. I think that's perhaps an area that we could use some buffing. We're a Kubernetes shop, so there are some things that aren't direct fits, which we're struggling with on the component Docker side, nothing major.

Kubernetes is a container-based run-time that works with Docker in terms of container-based applications, so we're a microservice based solution. Microservices are contained inside these containers which are managed by a run-time called Kubernetes. Kubernetes comes out of a Google enterprise. It's used by organizations like Netflix and apps to do continuous development deployment and use integration and development. It means that your container has this application lodging, around which all of the user authentication, run-time controls, and communications integration are handled by Kubernetes.

For instance, an application doesn't really see its DNS at all. It's completely abstract in a way. It is layers away from a virtual hardware. What it does is abstract that patient component into a nice package of business logic that is managed in a dynamic container, which takes care of all the run-time and communication issues that normally become a lot of the configuration overhead of an application.

Once you get your Kubernetes environment behind and organized, that forms a very efficient way to introduce these microservices in a dynamic way and to easily integrate and upgrade components rather than applications. You're much more granular in terms of your release capabilities and much more efficient in terms of how it's released and managed.

I would rate this around seven out of ten, because it has what we need, and it's easy to use.

SonarQube stability is fine. I would rank it high on the stability side.

We're not going to test scalability. Our volume is not that heavy. For this organization, it's not serious in scope.

Our users include about 60 developers and two dozen QA. On the QA side, there will only be about five really using it. There will also be two people on security. In total about 60 or 70 enterprise-wide.

We are in the introductory phase and we will, later on, make this a part of our release process.

It's pretty straightforward. It's a very easy thing to get up and running. It's the workflow side that you have to be careful about. Make sure that you don't overwhelm everybody with a report with a gazillion lines. Your real gems are in a very small percentage of it. So that's the configuration side, and that's what we're working on now. I've found that you have to tailor SonarQube's power to the maturity of the organization. Otherwise, you get a report with 2,000 items in it and it's hard to find the ones that are critical. This leads to data overflow and analysis paralysis at that rate.

We did an evaluation in about two weeks, so it was pretty easy to do and that wasn't full-time.

We did not use an integrator, reseller or consultant for the deployment.

From experience, you should just size the scale of what you're trying to do to the maturity of the organization.

So, it's been more than a year on since I wrote this review, so what has changed ?

Well. The first thing to say is that we (that is, a large multi-national financial services company) continue to use Sonarqube, indeed it has become mandatory for all projects (new and existing). We have introduced an aggregation portal which takes metrics from SonarQube via its API along with other sources, to provide a cross project and somewhat sanitised view for upwards reporting. It's important, we feel, not to try and hide issues, but at the same time not to 'set hares running' by exposing more senior management to metrics 'in the raw'. So instead, we gather all the evidence that we have, and add to that some constructive assessment from the lead solution designers, scrum masters and others, to provide more balanced and reasoned view. As we all know, there are a whole multitude of metrics baying for our attention, and it is not always obvious which are critical and which are less important (and that is often a factor of timing and priority).

One thing we did do this year is consider other complementary products, particularly in the area of identifying security vulnerabilities with both our own code bases and the open source 3rd party libraries that are routinely packaged with a released application. The latter category can often account for 80%+ of the actual app, so it's an important area not to neglect. Sonarqube does provide some support here i.r.o the integration of OWASP top 10, but it clearly isn't an area of strength when compared to more dedicated products. We did an RFP and have now selected two further products that will bolster this aspect considerably.

We have also moved forward with SonarQube in 3 important ways. First, we have upgraded our implementation to version 5.4 (prev. 4.5.x). This was important to many of our teams because some plugin support require the later version. The second change is that we have moved our implementation of the Sonarqube server into docker. Sonarsource provide an OOTB image on DockerHub which is a good starting point. We have enhanced it in a couple of ways to reduce the size and attack surface and also to add our specific config, but it was pretty easy to do so, so good job from Sonarsource here. The third difference is we have moved some of our install to use the Professional version rather than OSS. There were a couple of reasons, one was to access some commercial plugins which come bundled as part of the product and it made more sense (funding-wise). Another was to provide better support for a central SQ service. When I said 'some' of our installs, that was deliberate. We don't only provide SQ as a central PaaS, but also allow distributed DevOps teams to spin up their own, as long as they fully understand that operational support becomes their problem too of course (no free lunch here !). This works well for teams who want to manage more of their delivery pipeline rather than be part of a change control process where other participants might need to be consulted and perhaps engage in regression testing when changes are requested.

One significant change in v5.x is the movement of the database update to the server. This has a couple of important consequences. The first is that the build-breaker plugin is no longer useful since its harder to synchronise the fact that a build has failed with the update of the analysis outcome visible on the server. We use that plugin a lot, so it was a bit of a PITA. There is a compatible approach that SonarSource have documented, but personally I'm not a great fan because it increases the number of moving parts and thus the opportunity for something else to fail. But, with any upgrade there are always 'swings and roundabouts', and on the whole the positives outweigh the negatives (decoupling the client-side analysis from database update *is* on the whole a good thing). SQ v5 also comes with a bunch of new 'runners', now called 'scanners'. We have used the basic one, the Maven one and the MSBuild one, and all work fine. It's another change that you need to consider as part of migration, but not a massive one. Security controls have been enhanced in v5 and it's now easier to apply more granular access controls than in v4. For companies that outsource development work that's likely to be quite important (it is for us).

Licensing in the 'immutable server' world, whether that's docker or native Cloud remains unresolved. SonarSource seem a little behind the curve here, but we are talking to them. The key point is that we no longer stand up environments (including CI/CD pipelines) with any intention that they will have a 'shelf life' beyond their immediate use. Creating environments for specific use cases then tearing them down frequently (often this can be measured in minutes or hours) has become common-place for use and has tremendous advantages over previously used 'convergence' approaches using config management tools like Pupper, Chef or Ansible. Many vendors recognise this and have adjusted licensing arrangements, SonarSource aren't quite there yet (but they are willing to talk about it).

Anyway, that's probably enough of an update. I hope you find this, and the previous review helpful ?

Original Review (circa: 2014/15)

Moving to a largely evidence-based assessment is hugely beneficial, especially if you are managing out-sourced resources. It provides a clear definition of what acceptable quality actually means, and supports the decision of when you can stop, as well as what is not as there are no arguments based on an opinion. That said, metrics only take you so far, you still need smart people who can interpret and see beyond the base facts provided.

The ability to integrate analysis of software engineering metrics directly into the Development Lifecycle (DLC) in much the same way as any other practice such as Unit Testing. Specifically, developers run SonarQube analysis frequently and don’t commit changes to SCM when build breaker issues remain.

Early warning via CI build pipeline and especially setting up ‘Build Breakers’ based on a team or code base specific quality gate - a set of rules/thresholds that determine the most important measures for a particular code base.

Targeted improvement allows a team to identify specific areas of threat (e.g. TD) and then set purposeful goals to improve in those areas (rather than trying to improve everything).

The SonarQube community is very active which often means that finding solutions is a blog post away from other like-minded organisations. Community plugins are a staple for this product and have tremendous breadth and depth.

It would be utterly impossible to contemplate Continuous Delivery without including a major focus on ensuring affordable software quality. SonarQube plays a key role in this endeavour and provides Senior Management oversight across multiple project teams and business deliveries. Fits in very well with existing Continuous Integration build pipeline workflows. As we move towards Continuous Delivery ensuring a ‘no surprises’ release management.

Our software quality assessment at an affordable cost (licensing, time and effort). Previous attempts have failed to win the support of the development community (typically overly complex and intrusive and/or not sufficiently timely) without which the initiative will be doomed to failure.

• More granular security
• Simpler integration with JIRA
• It would be nice for a dashboard server to be able to address more than one database (this limitation tends to encourage either lots of small (team/project) servers or one uber server if you want to report across projects).

3years.

Originally we used Puppet to apply our specific configuration to our SQ install, and this was pretty successful albeit reasonably complicated. More latterly we have moved to using Docker. SonarSource provide a base image on DockerHub which is easy to extend for you own use case. We updated it to use a smaller footprint base image (Alpine) to reduce the size and attck surface, and then added our own set of plugins and other config. All straight-forward.

There were initially some questions about performance and in particular the location of the database (some suggesting that this needed to be physically close to the point of analysis to minimize network latency). However, this is highly dependent on the size of the code base under analysis (and the multiplicity of code bases). In our case we didn’t find any problem in running the database, server and analysis process in separate locations (RDS, EC2 and Jenkins respectively). Our largest code base to-date is around 500K lines.

Average. That said, considerable effort has been made to make the product largely self supporting at from the install and initial config perspective. Response to queries directly to SonarSource haven't always been particularly successful, but the community forum is pretty good.

We haven’t had a need for an official support contract with SonarSource. The open source community around SonarQube is very active and has met all of our needs to-date. That said, SonarSource do publish very helpful materials, documentation, blog posts, webinars etc. which we definitely take advantage of.

Yes. We had been using Coverity. However, whilst an excellent product with perhaps more capability, we found that it was more difficult to integrate into the development lifecycle and take up was relative modest. The sophistication of the solution was not well suited to our requirements in the sense that we are not producing commercial software but creating applications for internal use, and therefore the depth of analysis available was not really needed especially given the much higher learning curve. Also, licensing and platform costs were also high. We found SonarQube to be sufficiently powerful at a much more affordable price point.

More recently we have added two products with a specific focus on detecting security vulnerabilities. SQ does offer basic OWASP top 10 support within the language rule sets, but it's fair to say that this is probably not sufficient to keep your security folks happy. We definitely wanted to add support for scanning 3rd party libraries which probably make up 80%+ of our released app.

Creating instances of each of the major components (server and database) are very straightforward. Of course there are some complexities if you want to operate high availability, failover and so on, but no more so than any other application server. Given the stage in the lifecycle where SonarQube is used, it is in some ways less critical, so periodic outages can be tolerated. We typically operate an immutable server pattern so if/when we have server issues, we can easily destroy and re-create our environments or auto-scale them up and down as required. Integration into the CI world is easy (Jenkins plugin available or just use the command-line ‘runner’) and integration into the developer lifecycle also easy via plugins for mainstream IDEs (eClipse, Visual Studio, etc).

Using Docker simplifies things considerably. At the same time, the clutch of new 'scanners' does mean some extra work if you are migrating from v4.

In-house. The product is sufficiently simple that setting up the server environment requires some straightforward DevOps skills (spinning up servers and configuration management) and creating Jenkins jobs and installing IDE plugins. This is something that typically your developers should already be familiar with. We didn’t need any vendor support beyond the available documentation. Product training was not really necessary although we did run some awareness/101 sessions in-house, but more to promote why we wanted to go this route rather than any how-to technical skills.H

The only associated costs if you are following the OSS route are the platforms on which you will run your server and database, and any commercial plugins that you want to use (we only use a couple of those). There is a need to invest in a robust environment and some recommended practice but that is no different from any other similar software engineering process. We tend to prefer devolvement of responsibility rather than centralized control. This includes individual teams looking after their own infrastructure as well as determining their own priorities in terms of continuous improvement (albeit there are some standard measure that apply, for example unit testing, code coverage, technical debt and so on).

For v5.4 we moved one of our installs to use the Professional edition. This made sense for us because we wanted to use some of the commercial plugins that are already bundled as well as formalise support with SonarSource. We still use the OSS version for teams who don't need commercial plugins and want to manage their own SQ environment (see above comments).

Yes, and we did so again recently (2016). We had an encumbant Coverity solution which was very expensive and very under-used (too complicated). Since then we have also considered specific security analysis tools as complementary products (e.g. CheckMarx, Veracode, Nexus Life-cycle/Firewall, and a few others). We have since selected from these.

If you are looking at SonarQube you already realize the importance of software quality and it’s value proposition. Sometimes you just want to discover the types and severity of issues you have especially for legacy or inherited code bases (i.e. as a result of a merger). You should definitely follow best practice of not trying to cover every metric all at the same time, but instead pick out the two or three (at most) that are most critical to you right now (recognizing that this will change over time). Time based metrics are especially useful to help you understand if you are getting better or worse, and other well known strategies (such as ‘boy scout’) can also help formalise an improvement plan.

Perhaps the single most important consideration is to involve your development community right from the start (don’t try and foist a tool, set of skills or a change in process on them, as they will resist). Those guys are the ones that know where all the skeletons are and their buy in is absolutely critical especially if you need to change some existing behaviors. In my experience most software professionals are highly supportive but you should expect a few negative challengers).

We are a security organization, and we deploy security solutions and applications related to network for our clients. We mostly focus on open source products because clients don't like to have proprietary products because of the available budget for their different projects. We try to find the possible solution, and then we deploy the solution for them. Deployments are done on the AWS cloud as well as on-premises.

I came to know that there is a SonarQube solution that is used for clean and secure coding purposes and bug fixes in a large DevOps team. That's why I have deployed SonarQube. Currently, I'm testing SonarQube to demonstrate to my higher department what this tool can do. We are testing this solution for one of our clients, who may use it for two or three use cases during static code analysis and the software development life cycle. 

It's a great product. If you are in a hurry and just want to focus on the functional requirements of any kind of project, SonarQube is highly helpful. It enables the developers to code securely. 

SonarQube has a Community edition, which is open source and free. There are also three proprietary or paid versions: Enterprise edition, Data Center edition, and Developer edition. 

If I configure a project in SonarQube, it generates a token. When we're compiling our code with SonarQube, we have to provide the token for security reasons. If IP-based connectivity is established with the solution, the project should automatically be populated without providing any additional token. It will be easy to provide just the IP address. It currently supports this functionality, but it makes a different branch in the project dashboard.

From the configuration and dashboard point of view, it should have some transformations. There can be dashboard integration so that we can configure the dashboard for different purposes. 

It has been just three days since I deployed this solution. I have just configured the Community edition of SonarQube, and now I am searching for some Java products to test the solution. 

I have previously created a report comparing SonarQube with other products such as Micro Focus Fortify. SonarQube is way ahead than Micro Focus Fortify because SonarQube has a cloud solution. Micro Focus Fortify does not support cloud-based hosting.

The initial setup was simple for me. It was very straightforward and to the point. The documentation was also very much to the point and perfectly explained.

There are open source solutions for the Linux environment that let you automatically deploys everything in the new environment by using a specific file, but SonarQube doesn't have that file. That would be a plus point.

I deployed it myself. Because of our Linux environment, it took me around three hours. I was reading the documentation and learning about configuration-related parameters while deploying this solution.  

For the Community edition, there is no extra cost. It's totally free. The Enterprise edition, Data Center edition, and Developer edition are the paid versions. 

We have already used SonarLint. I am considering both SonarLint and SonarQube.

I always talk in favor of secure programming, secure coding. SonarQube is easy for me. I am recruiting buggy code with this, and it is reporting. It shows that this code should not be like this and the reason for it. For example, it shows that you should declare a static function, or why you should or should not initialize a variable. This is an amazing feature. I am enjoying testing SonarQube, but I don't know what is the feedback from a developer's point of view.

I highly recommend SonarQube. I would rate this solution a ten out of ten. 

We are using the free version of the SonarQube product. Be warned if you choose this version because it is lacking some of the capabilities and support. It is for this reason that we are currently considering migrating to a commercial solution.  

The main factor that makes the product valuable for us is that it is free because budget is always an issue. We do not have to pay for it, but there are many cons to using a free product at times. It is a very good tool even if it is free. The dashboard and the media that it provides are all quite helpful.  

We are always using SonarQube. But currently, we were trying to evaluate some more tools because Sonar in the free version has around 10 to 15 languages. If we go to the commercial version, they support 27 languages and there are a lot of limitations in the resources for traditional support which is not available for the free license users of Sonar.  

Integration is there with most of the tools, but we do not have full integration with the free version. That is why we were planning to go ahead and plan to work with some other commercial tools. But as a whole, Sonar will do what we need it to.  

Integration could be better in SonarQube in the free version. It does not have any bug tracking tool, like Jira. They are not integrated with enough additional programming tools.  

There is one issue with the dashboard. The dashboard which is there is okay. But sometimes if we have to work on multiple issues the application is giving us errors. Say we have five issues. All five issues might not be very important, so in cases where there are multiple issues, we would just want it to give us a warning about the important issue. It may be we will get to work on the things of greater importance and over-all have a better solution and we do not have to fix all five. Something like that would be good to help us to prioritize things so then we do not have to go into all the issues and fix them.  

We do have this categorization for major and minor issues, but let's say, again, if there are five major issues. I would like to maybe get a score involving the prioritization of these. Out of these five major issues, we should know which issue should be fixed first. This would give us a backup for planning and organizing the prioritization. It is that kind of data that we do not get on the dashboard. If we could, that would be helpful to give priority to the correct issues.  

We have been using SonarQube for maybe for a year or so. A little more than that.  

The stability is good. We are not having problems with the product failing.  

The stability of SonarQube is good. The scaling part is the problem. We cannot scale to all the other products that we want to use and we cannot improve and scale to other languages.  

The language issue is one that we are facing. If you want to use some languages like maybe tool languages or something people want to use, they are not all available in Sonar. In the commercial version of Sonar they may be available. But the free version, there are some limitations.  

So we do understand the limitations of the scalability. The free tool comes with its own advantages and disadvantages and limitations on scalability is one of the disadvantages.  

We do not really have very much contact at all with technical support because SonarQube quite user friendly and intuitive. Technical support is not actually available with the free product, but we do have access to community tools online.   

There was this one issue that we had where we had raised a question in the community. We found that if we scanned our project with SonarLint and if we scanned our project with SonarQube, it was giving some different results. SonarQube was showing some issues and SonarLint was not showing any issues at all. There was a clear difference in the report. But when we Googled this issue and looked on the support web site, we found now that SonarLint does not give you the errors around integration. When it comes to SonarQube, it automatically integrates with other processes and scans your port to that. SolarLint does not do this in the same way. This is why SonarQube might give you some errors that SolarLint does not.  

So we are not in contact the company support. When there are times when we do have an issue, we see what we can Google or the SonarQube community. Usually, we do find out our answers.  

The initial setup is quite straightforward. The setup process is very reasonable as far as it is logical and very simple. It doesn't take much time.  

We are using Sonar, and we also evaluated Checkmarx. The version of Sonar we are using is the free version of it. Checkmarx is quite a bit different and more helpful compared to Sonar. There are a lot of features missing in the free version of SonarQube that I want to have that already exist in Checkmarx.  

Anyone considering SonarQube should initially start with a free trial and then start doing an evaluation. If you have a list of target requirements which you are looking for and you can accomplish these things with Sonar, then you can go ahead and use Sonar. If you are looking for something for diving more deeply into your application security, then you can possibly start with it and scale it or use some other complementary tools. If you want to see your reports, and how your development is performing, Sonar is the best tool, I think.  

On a scale from one to ten, where one is the worst and ten is the best, I would rate SonarQube as a seven-out-of-ten.  

Our primary use for this solution is to improve code quality and reduce technical debt.

This solution is part of our pipeline. We use GitLab for source control and Jenkins to build management. Jenkins kicks off our SonarQube scans, we use Checkmarx for static code analysis, UrbanCode Deploy, and UrbanCode Release.

Using SonarQube has helped us to identify areas of technical debt to work on, resulting in better code, fewer vulnerabilities, and fewer bugs.

The most valuable feature is that it lays everything out and breaks it down, making it very easy to find and identify issues.

SonarQube is really good for finding coding standards when people deviate from what we have set corporately.

I find that some of the graphs around the measures are too fancy, and they do not mean a whole lot to me.

The solution is a bit lacking on the security side, in terms of finding and identifying vulnerabilities. By comparison, we run the same piece of code through both SonarQube and Checkmarx and there is no comparison between the vulnerabilities that each finds. Checkmarx may find fifty, whereas SonarQube will only find fifteen or twenty.

I haven't had any issues with stability and we see it as quite stable.

The only time we had an issue was because we used a third-party plugin for it to integrate with another piece of software and there was a versioning issue. Other than that, we haven't had any trouble. We've had to integrate it with our LDAP and everything seems to run quite smoothly.

We are in the process of bringing on more projects right now. We are running probably forty-five right now, and we haven't had an issue.

We have approximately one hundred users. There are some developers, but mainly product managers who are using it to track the numbers, and see if they're moving in the right direction or not. We have it integrated with some of our IDEs that we use corporately, and the developers are using it to check for bugs before they check code in.

Right now it's a small subset of the company that is using this solution, and there are plans to increase it. They are already starting to onboard more teams. Our DevOps manager is starting to push it upon more and more projects.

We haven't really had any issues, so I can't speak much about technical support. There is also a large community out there who uses it.

We were not using another solution prior to this one. As we've evolved, this is one of the tools that we decided to go with.

The initial setup was fairly straightforward. It's well documented and the documentation is easy to read.

We rolled it out to one server that was used as a POC, which was later moved into a production environment. We then rolled out a second one for Dev to test doing upgrades, which we do on a regular basis. Every time a new LTS (Long Term Support) version comes out then we run an upgrade.

Only one person is required in order to handle the maintenance. It is easy to maintain.

We handled the deployment in-house.

I do not know the metrics, but they are being tracked for the projects. Better code is being built with fewer defects, bugs, and issues. Our DevOps manager is increasing its usage, so he definitely sees value in it. 

My advice for anybody interested in implementing this solution is to start with the community version and try it out. It doesn't take long to see value in it, and it's very straightforward, easy, and intuitive to use.

There are add-ons that are available for purchase that we have not tried, although we're quite content with what we have right now.

I would rate this solution an eight out of ten.

This product has helped us improve the quality of code within the business and ensure all new developers keep to a similar code convention per project. This can basically be tracked back to saving the company money, because improved quality of the code means less technical debt which means it's easier to extend or add functionality to the code base. The quicker the development team can roll out changes, the less developer hours needed to implement the changes, which the company needs to convert into profits.

Most features in the product are very useful, but there are some parts that I personally use more than others.

1. Code Convention: Using the tool to implement some sort of coding convention is really useful and ensures that the code is consistent no matter how many contributors.

A very usual addition to this tool is an IntelliJ plugin called SonarLint, which integrates into your IDE, then allows you to run the convention rules file by file and receive immediate feedback when making changes. This removes the need to push to the server before finding out what issues you need to resolve.

2. Technical Debt: Being able to see how much technical debt there is within the project is useful, especially if your change increases this value. It's a good way to determine whether your change is improving the overall code quality or not.

3. Graphing: The tool has some very useful graphs which give you an overall view of how the code looks and/or changes with time. A graph that I find useful is the bubble chart. It shows three different metrics in a 2D graph. It shows the number of lines of code versus the number of issues in that project. The third dimension is the size of the bubble, which is technical debt in the project. So it's very easy to see which projects need immediate attention, if they are in the top-right quadrant of the graph as a very large circle, i.e., high number of issues, high number of lines of code, and high technical debt. Seeing which project/submodule is in which quadrant of the graph shows where work is needed. You can also drill into the project and see any submodules within that project as well. Very useful.

• Upgrading the version of the server is a bit cumbersome and could be made slightly easier. Allowing admin users to upgrade the software through the front-end would make upgrading easier.
• Another improvement is with false positives. Sometimes the tool can say there is an issue in your code but, really, you have to do things in a certain way due to external dependencies, and I think it's very hard to indicate this is the case. There is a way to mark the code/method with the issue number, but having to add comments/annotations in your code for your static analysis tool feels wrong to me.
• Being able to have different groups or projects within the same server would be nice. Currently, I have a Sonar machine for production code (master branch) and UAT code (UAT branch), so when each branch is built in our continuous integration server it publishes to these two Sonar machines. What would be nice is if I could create subgroups within a single SonarQube server for each environment to remove the need for two separate machines.

It seems a lot more stable in the current versions of the product. I have never had major issues though, so I would say it's pretty stable.

I haven't yet found any scalability issues, although with the upgrade to version 6, they have moved the processing of the stats from outside the server to inside the server. What I have noticed is that the machines running SonarQube are using a lot more resources, as the processing is done server side. This means that I need to increase the resources allocated to the machine. If I was running this in the cloud, it would be easy, as I would create a larger instance for the service. But as I have this running on a physical machine, I am limited to what I can allocate.

I haven't used their technical support.

Yes, I have used individual components which SonarQube uses, such as FindBugs, but having the static analysis run and reported back within a continuous integration server. This gives you back some of the results, but SonarQube is a single, complete solution for static analysis and has added improvements like a great UI and visualisations.

Initial setup was pretty easy. I currently run this in a virtual Linux (Ubuntu) machine using Vagrant and VirtualBox. Installation using apt-get was pretty simple. I then bundled it all up into a new Vagrant box which means I can spin up a new instance of SonarQube whenever and wherever I am (like a custom AMI on AWS), but locally.

I am using the open source version of the product, so no cost. The licence is standard open source licensing, LGPL, so nothing to advise really.

I didn't. I am not sure if there are any other open source static analysis tools as good as this that I have found; Well at least three or four years ago there weren't.

I would advise to get it done sooner rather than later. The sooner you have a better understanding of the state of your code base, the sooner you can make better business decisions based on that information.

Also, even though you may be a sole developer, I think it's still useful to use this tool and have these metrics at your finger tips. It's like version control, even if you are the only developer, I think it should be used for everything you do.

We generally use the solution in order to do static code analysis.

What I like about SonarQube is the integration of the pipelines. It is pretty easy. 

The reporting and the results are quick. It gets integrated within the pipeline well.

The solution is very stable.

The scalability is very good.

We found the initial setup to be straightforward.

The solution has a very shallow SAST scanning. That is something that can be improved. 

I'm not sure if there is any plan for having DAST, as well, which is the dynamic scanning. If they offered that in SonarQube that would be ideal. I'd like to know if there is a plan or roadmap for Sonar to have that included. However, right now, at least, from the SAST perspective, it can improve.

The pricing could be reduced a bit. It's a little expensive.

We've been using the solution for the past two years or so. It's been a while.

The solution is pretty much stable. Sometimes we have observed some issues when there are a lot of services getting deployed together. We have noticed some resource constraints sometimes. Occasionally the CPU and memory get affected. That was the only thing. It could be due to the resources that we have provided and maybe not the fault of the product itself.

I don't have the user count, however, from the application perspective, we have around 30 to 50 applications, which are on SonarQube. All of the teams that are managing those applications have access to that.

It is integrated within our pipelines. It gets used every day.

Right now we are not scaling the solution. It is just one server that we have. It is static of sizing and we do not scale it.

We do have an enterprise version, however, that does not include the support right now.

If we have any issues we're trying to resolve them on your own. So far, that has been sufficient.

We are also onboarding Checkmarx. We use both solutions.

We are not replacing anything. Maybe we will use both in conjunction. Checkmarx provides DAST, whereas this product does not. 

The initial setup is pretty simple.

I do not recall the exact amount of time it took to deploy the solution.

It does not require a lot of maintenance. It's just that whenever any latest version is coming in, we just have to upgrade it.

We did the installation on our own. We did not need the assistance of any outside resources such as consultants or integrtors. It was all handled in-house.

What we are looking at in the future is a bit of a price reduction. The pricing that we have been quoted for the next version is a little expensive. The pricing could be also a bit reduced.

We are just a customer and an end-user.

While we installed the solution on the cloud, we host it on our machines.

I would recommend the product to the companies or the teams who are building from scratch, and they don't have anything for doing the scanning of their products. That is something where SonarQube can be pretty helpful.

It's good for a very small company with a limited number of products, which do not have a lot of compliance and security-related requirements that big enterprises might have.

I would rate the solution at a six out of ten.

I'm a user also, but I'm also responsible for information security.

I am the principal of security in the office. I'm the one that actually advises people about enhancing or incorporating information security aspects. Right now, we are using a community version. We have yet to subscribe for the enterprise license because we need more disciplined developers first.

Within our organization, there are roughly 14 people using this solution.

We use it to find the scoop, or the use, for peer review for the developers. It will require more time, to get used to it and to get trained. My team is very small and I am part of the development team — I'm in the security team but I'm also part of the development team. I am helping to build this along with the team.

The product itself has a friendly UI. It's easy to use and we understand how to manage the admin control panel, it's really quick. It's really easy to perform admin jobs using the control panel. 

The tools are really easy to use. With the coding, we can build a bunch of rules that apply for each programming language, for example, CSS, Java, and more. Even with the community version, we can still set up rules. We accommodate them and they give us the best quality. It's been a great experience so far.

We could use some team support, but since we are using the community version, it's not available.

Also, because we are using the community version, we have some problems from time to time regarding the SSO logins.

Sometimes you need more time to configure things, to edit some profiles.

SonarQube has come to the end of the project phase. The development team doesn't really utilize this because it's in the product development phase. They need more paths and delivery — they don't really care about security. But now, since we are also certified technical security, we can go ahead and provide that for them.

In short, communication needs to be better.

Automation could be better. Sometimes by default, you need to configure some rules regarding detection. You need to have some parameters set regarding false-positive risk. 

We have had SonarQube for over a year, but we have only been using it for the past two months.

With the use of community version, we already have utilized and carried out our needs to fulfil application security at the earlier stage with small medium SDLC Team.

The initial setup was very straightforward. Overall, deployment took roughly one week.

There are so many qualitative tools other than SonarQube, but I think it's the only platform that is open-source; however, it doesn't cover you end-to-end — from the static, dynamic, and interactive source.

Once we're done with SonarQube, we will switch to a proprietary tool, like Qualys — something that provides more end-to-end — but before we can do that, we need more people who know how to properly run the software.

Overall, I would recommend SonarQube for your initial software quality.

On a scale from one to ten, I would give this solution a rating of eight.