We’ve been using the CycloneDX maven plugin and CycloneDX gradle plugin with good results. I’m thinking the output bom.xml could be imported by our subsequent sonar analysis in the CI pipeline.
What sort of checks would you be wanting to run against the SBOM?
1 Like
The main thing that I would use on the regular basis is the search on the modules - if Sonarqube is able to answer which projects have the dependency module A of version 1.2.3 - it would be ideal
If I read between the lines, I believe you would expect SonarQube to ingest SBOM files so that then you can search if one of your projects (or your Applications, or Portfolios) is impacted by a dependency “A” v1.2.3 that is known to contain a vulnerability. This is what I’m calling Impact Analysis.
Am I correct?
1 Like
Butting in 
: as someone quite new to devsecops, that would be one of my use cases. Another would be (if this is possible) to see what full chain of dependencies would be affected by resolving such a security issue. For instance, “updating Django to 4.0.8 would require updating these 10 other packages, but would break compatibility with this other package”. (I don’t know if an SBOM generation tool would include quite that depth of info.) The process for carefully updating pinned versions in a requirements.pip file can get tedious when one has a bunch of projects.
I think the ability for Sonar to ingest a sBOM could be a pretty powerful feature. We currently use Sonar (SonarCloud) as our technical debt dashboard. OSS and OSS vulnerabilities are part of technical debt but we currently have to role our own solution to keep track of these types of issues. A good use case for Sonar and sBOMs would be:
Given I generate a Software Bill of Materials (sBOM) for my project
And the sBOM is in an industry standard format (CycloneDX or SPDX)
When I post my sBOM to Sonar
Then Sonar will cross-reference each package with a OSS vulnerability DB
And Sonar will report on all OSS Vulnerabilities in my project
For full disclosure we are currently using CycloneDX Node.js sBOM Generator and CycloneDX Maven sBOM Generator to produce a sBOM. Then using osv-scanner to scan our OSS packages for vulnerabilities.
1 Like
GitHub produces SPDX-2.3 SBOM files. It would be nice if SQ could import and parse these as part of the report.
Not only is SBDX a recognized standard, for many projects, this can be an alternative to running a scan which is important for legacy apps that exist in SQ but aren’t under active development.
I know that Checkmarx creates SBOM files for the projects that it analyzes and I’d like that not to be the thing that moves us away from SQ.