Managing dependencies

SonarQube Server can perform software composition analysis (SCA). When you analyze a project, SonarQube Server lists its dependencies and the dependency risks raised during analysis (if any). You can also export the software bill of materials (SBOM) for your project.

Dependency analysis is available for the following languages: 

• JavaScript/TypeScript
• Java (Maven, Gradle)
• Python
• C# / .NET

Viewing the list of dependencies for a project

After you analyze a project, a list of dependencies becomes available in the SonarQube Server UI under the Dependencies tab. It is updated with each analysis. 

The following information is displayed for each dependency:

• Name
• Version
• Location in the project
• Package manager
• License
• Whether it is used at runtime or during development

Click on a dependency in the list to get a detailed view page for that dependency. 

About dependency chains

Because your project can be built using components that are themselves built using other components, a dependency can be direct or transitive. 

For example In a Project > Component 1  > Component 2 scenario: 

• the dependency between Project and Component 1 is direct 
• the dependency between Project and Component 2 is transitive because Component 1 is built using Component 2

In the SonarQube Server UI, the detailed view of a dependency lets you know if it is direct or transitive. If it is transitive, the full path to the dependency is displayed.

Reviewing and fixing dependency risks

From your project’s page, go to the Dependency risks tab to see the list of dependency risks for your project. From there, you can Sort dependency risks and apply Filters.

Each dependency risk has an assigned type and severity.  

Clicking a dependency risk in the list opens its detailed view. From there: 

• the Affected dependency section provides details on the dependency that raised the risk
• the What is the Risk? tab gives you more information about the dependency risk
• the How can I Fix it? tab lists the known dependency versions and indicates if upgrading to that version will partially or completely fix the dependency issue

How Sonar evaluates dependency risk priority

Sonar uses a holistic approach to determine the severity of a dependency risk. The evaluation is based on four factors:

• Risk - how bad is the vulnerability
  • Measured by CVSS
• Evidence of exploitability - has it been seen to be exploited
  • Measured by CISA KEV
• Predicted exploitability - is it likely to be exploited in the future
  • Measured by EPSS

Sonar combines these factors to assign a severity to a discovered vulnerability. The table below lists the severity levels and their definition.

Getting the software bill of materials (SBOM) for your project

About SBOMS

A software bill of materials (SBOM) is an inventory of components your project is built with, including details such as the component name, version, and license. 

Because your project depends on these components to build and run your software, getting the SBOM for a project is a key element in the remediation of dependency risks. 

SBOMs are used to track and prioritize known security problems and remediation timelines. Compliance teams can use SBOMs as an index to keep an inventory of licenses in use. Developers can use SBOMs to manage dependencies. All of this creates greater interoperability and efficiency within an organization. It is a shared language for all of these teams that can be passively generated and maintained based on application builds.

Sonar supports exporting an SBOM in both major SBOM formats: Software Package Data Exchange (SPDX) and CycloneDX.

Exporting the SBOM for your project

From your project’s overview page and the Dependencies tab, you can click the Export SBOM button to download a SBOM file that corresponds to the project dependencies for the branch that you’re viewing.

SBOMs are available in the CycloneDX and SPDX formats, in both XML and JSON form.

Customizing the dependency analysis

The following parameters have an influence on the results of the dependency analysis.

Troubleshooting

Docker installation

You may need to update the container and add sonar.sca.available=true to /opt/sonarqube/conf/sonar.properties, either via building a new derived image, or by mounting a volume at that point that has an updated sonar properties file.

“Dependency analysis: Unable to connect to SCA service” warning

Sonar will raise warnings when dependency analysis fails. If you see “Unable to connect to SCA service” warning, that means Sonar was unable to authenticate to the SCA service for analysis. To prevent analysis from failing:

• ensure that api.sonarcloud.io and scanner.sonarcloud.io are reachable from your SonarQube Server
• ensure that you have properly onboarded your ServerID for early access

Unable to see Dependencies and Dependency Risks unless logged in

If you have public projects on your servers, you will not be able to see Dependencies and Dependency Risks unless you are logged into your SonarQube Server environment. This restriction will be lifted with the General Access release.

Unknown lifecycle phase error

When analyzing some java projects, you may get an error that says "there was a problem running mvn dependency:tree, and the following message in the details of the error:

 [ERROR] Unknown lifecycle phase "/some/path/.m2".

This is due to a conflict between a MAVEN_CONFIG environment variable that was present during analysis and the mvnw maven wrapper in your project directory. You can solve this by doing one of the following:

• unset the MAVEN_CONFIG environment variable
• update the maven wrapper in your repository by running ./mvnw wrapper:wrapper, and commit the result
• force the use of `mvn` instead of the wrapper by setting the sonar.sca.mavenIgnoreWrapper property to true

Maven Tycho project components are listed as dependencies

If your Maven project uses Tycho to build Eclipse plug-ins, some components that belong to your project might be categorized as dependencies and appear in the Dependencies tab of your project. 

To prevent this from happening, you can use the sonar.sca.mavenOptions property with -Dtycho.target.eager=true set as its value. For example, in your pom.xml file:

<properties>
<sonar.sca.mavenOptions>-Dtycho.target.eager=true</sonar.sca.mavenOptions>
</properties>