ppkarwasz commented on PR #3502: URL: https://github.com/apache/solr/pull/3502#issuecomment-3229683793
> Long answer: The Dependency Graph was pulling in Gradle/plugin tooling (buildscript classpath, > plugin classpaths, annotation processors, etc.), which added noise. I’m pruning the submission to > keep only real app/test classpaths and exclude tooling. I also tag scopes so we can focus security on > what actually ships. Looks great, thank you for sorting that out! :100: One of the reasons I had dismissed the Gradle Dependency Submission action in my investigations was precisely the **large number of non-runtime dependencies** it was reporting. As you’ve shown, I just hadn’t looked deep enough into the plugin’s configuration options. My approach was heading in a different direction: * Generate an SBOM for the `tar.gz` distributions. * Submit that SBOM to GitHub’s Dependency Graph. The motivation for focusing on the `tar.gz` distributions is that we need to distinguish between **shipped** and **non-shipped** dependencies: * If `solr-core` depends on something but that JAR is **not shipped** in the distribution, then any vulnerability has the same implications as for any other Java **library**: end users can update it themselves, so it’s lower priority. * If the dependency **is shipped**, however, then every vulnerability potentially requires a new Solr release or at least a `not-affected` VEX statement. That’s why, at least initially, I would prefer to limit submissions to dependencies that are actually shipped, ignoring the broader `runtimeClasspath`. (From my analysis, there are roughly half a dozen low–moderate vulnerabilities in shipped dependencies right now.) I didn’t finish mapping all configurations that represent shipped artifacts, but I did confirm that `packaging` and similar configs don’t work well (they seem to be computed too late for the plugin to pick them up). What **does** work for me are these custom configurations in `:solr:server`: ```groovy // === Custom configurations used to assemble the Solr server binary distribution === // 1. Jetty Bootstrap JAR // Output Path: server/start.jar startJar // 2. Server Libraries // Output Path: server/lib/ // Description: Core runtime libraries (mostly Jetty-related JARs). serverLib // 3. Extended Server Libraries // Output Path: server/lib/ext/ // Description: Optional runtime libs like logging (SLF4J/Log4j) and metrics (Dropwizard, etc.). libExt // 4. Solr Core JAR // Output Path: server/solr-webapp/webapp/WEB-INF/lib/ solrCore // 5. Solr Web Application Libraries // Output Path: server/solr-webapp/webapp/WEB-INF/lib/ webapp ``` So far I’ve only analyzed the `server` folder of the distribution, but those configurations appear to line up exactly with the shipped JARs. That means we could narrow the submission with: ```sh DEPENDENCY_GRAPH_INCLUDE_CONFIGURATIONS="startJar|serverLib|libExt|solrCore|webapp" ``` I'll look at the remaining components of the distribution archive this week. **PS:** I’ve also looked into Dependabot’s support for updating Gradle lock files. While basic support has been available since June, there are still unresolved issues when a project uses both **lock files** and **version catalogs** (see dependabot/dependabot-core#12557). -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
