SBOM for SonarQube

I was wondering, if there is an SBOM available for SonarQube itself.
I found https://github.com/SonarSource/sonarqube/dependency-graph/sbom, but this only results in error: "Not Found", while the dependency graph itself seems to be available (https://github.com/SonarSource/sonarqube/dependency-graph)

Hey there.

As a SonarSourcer I have access to download the SBOM… but as soon as I’m unauthenticated I lose that access. Also of note, only frontend dependencies are listed.

I’ll follow-up on this internally. In the meantime, regarding backend dependencies, you may find the dependency-license.json file of a SonarQube installation directory useful.

Can you explain how you would use an SBOM? Is it just a checkbox, or are there certain things you’re looking for (licenses used, etc.)

Hi Colin,

thanks a lot for your swift response!
Our security team is starting to request SBOMs for all applications that are used in production.
This is going to be put together in an application repository and used for risk assesment in our environment.

We are scanning our production cluster with kubeclarity as well and currently it doesn’t look good for SonarQube as it lands first place when it comes to critical vulnerabilities :confused:

I was wondering, if this analysis was accurate and would love to get an SBOM (at best accompanied with a VEX) to provide information reviewed by the vendor to our sec team.

SonarQube will probably not be the first application to get the attention of our sec team, as it’s used and accessible by the dev team only, but given the rising threat activities in recent times, it may be necessary for us to remediate / workaround at some point.

Hey @guidow!

I don’t know Kubeclarity, but I can’t help but mention that I think (I speak I) tools like this are often noisy (raising lots of potential issues) to prove their value, while not pointing to many (or any) real exploitable vulnerabilities. Especially since there are a few layers to the SonarQube docker image (like the eclipse-temurin base image, of which we care only about a few parts)… it’s almost impossible to get a clean scan.

We run dependency checks of our own and regular penetration testing. I’d reccomend checking the SonarSource Trust Center for more resources (like our public security profile on Whistic).

I don’t have an SBOM to share, but I’ve inquired internally if we plan on sharing one publicly in the near future.

Hey @Colin,

I agree and that’s why I think a moderated response from the vendor is very important.
Kubeclarity does a simple dependency analysis and aggregates all known vulnerabilities of which some may not be relevant. That’s where the VEX comes into play and for unreachable code in a dependency for example it should be explained by a vendor, why a known critical vulnerability in a dependency does not apply for the given product and possibly as well when it is planned to update the vulnerable dependencies or why it might not be possible.
We are working together with highly sensible customers and do this for our products already and I think it would be quite important to keep dependencies as up to date as possible and let customer know, which critical known issues are relevant.
To point out that tools like this may generate noise and don’t address the findings in details seems a little off to me.

I wasn’t able to download the detailed pen test reports as they don’t seem to be public and the information available without creating an account seems very general/high level.

Best regards,
Guido

Hey Colin,

did you get any feedback internally already?
As well, is there an officially documented dependency update strategy for sonarqube?
It seems that quite a few of the reported dependencies with vulnerabilities are quite old.
Even the recently updated Sonarqube 10.2.1 docker image contains vulnerable dependency versions that are over a year old and have already been updated:
https://hub.docker.com/layers/library/sonarqube/10.2-developer/images/sha256-b54a65bab5c58f74f68d0f4ad05c9753517009cf1e7af6fd48f8ee37a2963af5?context=explore

Best regards,
Guido

Hey Guido,

No updates to share on my end, but a conversation opened up internally (the gears turn slowly). My previous statement stands: