Hi Piotr, I think I can answer most of your questions, as I have migrated the project to use Gradle's version catalogs.
> How are vulnerable dependencies handled? Are JIRA issues created automatically for such cases? When it comes to vulnerabilities and vulnerable dependencies, we have to distinguish between vulnerabilities that affect Apache Solr, and the ones that don't. When a vulnerability is found in a dependency, a CVE is usually published and the *security page*[1] can be taken for advice here. If the dependency is affecting the security of Solr, the vulnerability is resolved usually by updating the dependency and releasing a new version (at least for what I know). I believe that in such scenarios it also makes sense to create a Jira issue. As of my knowledge, this step is handled by devs and is not automated yet. > Are transitive dependencies also monitored and updated? Yes. We are using gradle's *version catalogs*[2] and use that in combination with gradle's dependency *locking mechanism*[3]. This is the reason why we have custom scripts that need to be executed when updating a dependency, as there is no simple way of doing so in Gradle. > I’m more familiar with the Dependabot ecosystem There was an attempt[4] from my side to introduce dependabot and replace renovatebot, which would not require a separate project anymore and the overall setup would be simpler. However, in the attempt of introducing dependabot I noticed that it is not capable of executing additional gradle tasks for updating the lock, license and notice files. This required multiple changes in our workflows, which was not ideal. So we went with renovatebot as it was easier to update by that time. The PR that I linked contain a lot of observations that I have shared in case anyone else wants to continue where I left off. > [...] but SBOMs could be a more universal data source. In the attempt I mentioned above, the dependency submission of dependabot is included. I believe it should be easy to add the dependency submission to our project without much effort. I think it is just a workflow file that needs to be copied and some project settings on Github that need to be updated. About your goals: our renovatebot creates automatically pull requests for all dependencies in our version catalog. In case a vulnerable dependency is a transitive dependency, it is possible to add it to the version catalog and manually update the transitive dependency separately (in case the dependency that uses it has no updates yet). Now when it comes to VEX files I am not sure what options we have here, as I am not familiar enough with this topic. More information about how dependencies are updated can be found in the two files we have about dependencies[5]. Please note that between 9.x and 10 (current main) the process is slightly different, so you have to checkout both versions of the files. Two last and important notes: 1. The migration to Gradle's version catalog and locking mechanism introduced a huge gap between 9.x and 10 (current main). This gap has as an effect that backporting dependency updates to 9.X is cumbersome and requires manual work. If I remember correctly Jan wanted to configure renovatebot to address this gap by creating separate PRs for 9.X dependency updates, but I am not sure what the current status of this is. 2. Many of the dependency updates in 10 (current main) cannot be backported to 9.x as there are dependencies (transitive and not) that do not support the older JDK version we have configured in 9.x. So be cautious when it comes to backporting something. Best, Christos [1] https://solr.apache.org/security.html [2] https://docs.gradle.org/current/userguide/version_catalogs.html [3] https://docs.gradle.org/current/userguide/dependency_locking.html [4] See PR https://github.com/apache/solr/pull/2880 [5] See https://github.com/apache/solr/blob/main/help/dependencies.txt and https://github.com/apache/solr/blob/main/dev-docs/dependency-upgrades.adoc On Wed, Jul 23, 2025 at 9:16 AM Piotr P. Karwasz <pi...@mailing.copernik.eu> wrote: > > Hi all, > > I’d like to better understand how dependency upgrades are currently > managed in Solr. > > I noticed that Jan runs a custom Renovate Bot [1] which opens PRs when > upgrades are detected. I have a few questions about the overall process: > > - How are vulnerable dependencies handled? > - Are JIRA issues created automatically for such cases? > - Are transitive dependencies also monitored and updated? > > I’m more familiar with the Dependabot ecosystem (GitHub Security Alerts > + automated PRs), but I’m happy to work with the existing setup, > whichever tooling the project prefers. > > My goal is to help ensure the following: > > 1. A JIRA issue is created whenever a vulnerability is detected in the > dependencies of any 9.x release. GitHub uses a submitted Dependency > Graph to generate alerts, but SBOMs could be a more universal data source. > > 2. A PR is opened for the affected dependency to test if it can be > upgraded automatically to a non-vulnerable version. > > 3. A PR is also created for a VEX file, indicating that the > vulnerability is `in_triage` and pointing to the JIRA issue. This > provisional VEX entry could be published right away, or I can follow up > with a detailed evaluation. Once VEX tooling is in place, the PR will > contain enough context to help maintainers assess the issue easily. > > Looking forward to hearing your thoughts! > > Best, > Piotr > > References: > [1] https://github.com/solrbot/renovate-github-action > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org > For additional commands, e-mail: dev-h...@solr.apache.org > >
