Hi Christos, On 23.07.2025 13:57, Christos Malliaridis wrote: >> 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.
Thank you for the explanation. I think I can help with some automation here to: - Open a JIRA issue to evaluate the effects of the given CVE. - Open a PR linked to the JIRA issue to try upgrade the dependency to a version without the vulnerability. Getting rid of the vulnerability is probably useful even if it is not exploitable. >> 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. >From what I understand the answer is: yes, if the dependency is in the catalog. We have a similar problem in Log4j: we don't get notifications for transitive dependency that don't figure anywhere in the POM files. >> 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. Since Dependabot is Open Source, this problem should be fixable. I'll look into it. As I understand, except this problem, you don't have any specific preference between Dependabot and Renovatebot? > 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. There are a couple of ways to submit dependencies to the GitHub Dependency Graph: 1. Automatic submission can be enabled through project settings. In our case we would need to extend `.asf.yaml`. The effect is a rather crowded graph[1] with most *build* dependencies (except Gradle and its plugins as far as I can tell). 2. As you mention, dependencies can be submitted by a workflow, e.g. using the `github-dependency-graph-gradle-plugin`[2], which gives some options on which dependencies to include and which to ignore. 3. Dependencies can be submitted using an SBOM[3], which might be the less verbose option, since the SBOM might include only those dependencies that end up in the `*.tgz` archive. > 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). I guess pinning a transitive dependency to avoid a vulnerability is something Dependabot could also learn to do. > 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. Regarding VEX-es most of the automation will be provided by OpenRefactory in the following months[4]. Right now I am just wondering what is the right place to integrate the tooling that will be provided. > 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. Thanks, I'll certainly read those. Piotr References: [1] https://github.com/vex-generation-toolset/solr/network/dependencies [2] https://github.com/gradle/github-dependency-graph-gradle-plugin [3] https://docs.github.com/en/code-security/supply-chain-security/understanding-your-software-supply-chain/using-the-dependency-submission-api#submitting-sboms-as-snapshots [4] https://lists.apache.org/thread/8yzoyn4xxy25x9thd7bcq1cz5soj619q --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org For additional commands, e-mail: dev-h...@solr.apache.org
