> For the complete documentation index, see [llms.txt](https://docs.sonarsource.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.sonarsource.com/sonarqube-server/2025.2/project-administration/managing-dependencies.md). # Managing dependencies The features described on this page are [Early Access](https://www.sonarsource.com/legal/early-access/) features. 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 og 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](http://first.org/cvss) * Evidence of exploitability - has it been seen to be exploited * Measured by [CISA KEV](https://www.cisa.gov/known-exploited-vulnerabilities-catalog) * Predicted exploitability - is it likely to be exploited in the future * Measured by [EPSS](http://first.org/epss) Sonar combines these factors to assign a severity to a discovered vulnerability. The table below lists the severity levels and their definition. | **Sonar dependency risk severity** | **Definition** | | ---------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Blocker |


| | High | | | Medium | | | Low | | | Info |

Any of the following is true:

Note: this categorization for “Info” overrides any criteria that would place the issue into Critical/High/Low


| ## Getting the software bill of material (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)](https://spdx.dev/use/specifications/) and [CycloneDX](https://cyclonedx.org/). ### 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. There is no history for SBOMs at this time. This means that you can only download the SBOM from the latest analysis for that branch. If you want to get a specific SBOM for a given version of your software, you need to extract it at the right time and save it somewhere outside of SonarQube for later use. ## Customizing the dependency analysis The following parameters have an influence on the results of the dependency analysis. | **Parameter** | **Type** | **Default** | **Description** | | ------------------------------------ | -------- | --------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | sonar.sca.enabled | Boolean | true | Whether to perform Software Composition Analysis (SCA) on this project. Set it to false to disable SCA for this project. | | sonar.sca.debug | Boolean | false | Enables debug output from the scanner without having to enable debugging at the server level. | | sonar.sca.excludedManifests | String | \ |

A comma-separated list of glob patterns of paths to not include as part of analysis.

For example, to ignore all manifests under the tests/ and fixtures/ directories, set:

sonar.sca.excludedManifests = “tests/, fixtures/”


| | sonar.sca.recursiveManifestSearch | Boolean | true |

Whether to search the entire project tree for manifest files such as pom.xml or packages.json.

Recursive search may pick up unintended manifests, such as manifests in test cases. If so, either disable this option, or use this option in conjunction with sonar.sca.excludedManifests.

| | sonar.sca.allowManifestFailures | Boolean | true |

When performing analysis, Sonar will attempt to run your build tools (such as Maven or Gradle) to create a full dependency graph.

By default, Sonar will not fail the analysis if these tools fail, and will return information on a limited set of dependencies. Set sonar.sca.allowManifestFailures to false to force a failure in this scenario.

| | sonar.sca.goNoResolve | Boolean | false | Disables trying to automatically resolve a Go lock file. | | sonar.sca.mavenNoResolve | Boolean | false | Disables trying to automatically resolve a Maven lock file and dependency graph file. | | sonar.sca.mavenForceDepPlugin | Boolean | true | Try to ensure Maven Dependency Plugin is installed even when it’s not available in the environment. | | sonar.sca.mavenIgnoreWrapper | Boolean | false | Disables looking for a Maven wrapper script mvnw. Set this to true if the default maven wrapper in your PATH is not functioning. | | sonar.sca.mavenOptions | String | \ | Sends additional options to any Maven commands used to generate the lock file and dependency graph file. | | sonar.sca.gradleNoResolve | Boolean | false | Disables automatically generating a Gradle dependencies lock file. | | sonar.sca.gradleConfigurationPattern | String | \ | Java regex of configurations to include, passed to gradle via `-PconfigurationPattern`. When unset, all configurations will be resolved. | | sonar.sca.pythonBinary | String | /usr/bin/python | Path to the specific Python binary that should be used if lock files need to be generated. | | sonar.sca.pythonNoResolve | Boolean | false | Disables automatically generating a Python lock file | | sonar.sca.pythonResolveLocal | Boolean | false |

When generating a python lockfile, dependency resolution will be done in a temporary virtual environment.

Set this to true to skip creation of the virtual environment and resolve against the local python environment.

| | sonar.sca.npmNoResolve | Boolean | false | Disables automatically generating a lock file for an NPM project when `yarn.lock` or `package-lock.json` are not present. | | sonar.sca.npmEnableScripts | Boolean | false | By default, when generating a lockfile, the `--ignore-scripts` NPM/Yarn option is passed to ignore any prep scripts. If prep scripts are needed to properly generate dependencies, enable this option. | | sonar.sca.nugetNoResolve | Boolean | false | Disables automatically generating a lock file for a Nuget project. | ## [Troubleshooting](https://docs.sonarsource.com/sonarqube-server/2025.2/project-administration/managing-dependencies/#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](https://projects.eclipse.org/projects/technology.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: ```cobol -Dtycho.target.eager=true ``` \\ --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.sonarsource.com/sonarqube-server/2025.2/project-administration/managing-dependencies.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.