How to handle multi-module maven vulnerabilities alongside distribution bundles like war, zip and windows installers.

[jodygarnett]

I am responsible for the GeoServer project which is a Java web application for making maps. I have run into a fundamental question on how dependant handles transitive maven dependencies, and what are the expectations for listing download or installation artifacts along side the a software component in a multi-module project setup.

I will use specifics rather than a hypothetical setup to avoid speculation.

In Maven ecosystem:

• org.geoserver.web:gs-web-core - defines an admin console for configuration
• org.geoserver.web:gs-web-wfs - depends on gs-web-core above and functionality with additional admin console screens
• org.geoserver.web:gs-web-app - defines a web application archive geoserver.war that both depends on the components above, and includes these components in a manner similar to a zip file with some extra web.xml driving directions for deployment

Downloads:

• geoserver-2.24-war.zip distribution: zip bundle of the geoserver.war web application (including vulnerable software component) and installation instructions for use with your own application server (such as Apache Tomcat)
• geoserver-2.24-bin. zip distribution: zip download includes an application server, the web application (including the vulnerable software component)
• GeoServer-2.24.2-winsetup.exedistirbution: NSIS windows installer, an executable that that installs a windows service, including an application server, and the web application (including vulnerable component)

When reporting a vulnerability how much can dependabot figure out from the maven dependency graph, and how much do we need to state up front:

• gs-web-core: a specific software component with the problem (something you could scan for by name and identify as being vulnerable)
• gs-web-wfs: software component requires a vulnerable component to operate, transitive dependency
• gs-web-app: software distribution that includes the components, has full dependency information available on transitive dependencies
• distribution bundle with instructions
• distribution bundle with executable required to run
• windows installer

As shown above we have been listing only the most specific software component with the vulnerability. Is their an expectation to list more?

[jonjanego]

Hi @jodygarnett - it sounds like your project might benefit from submitting all of its dependencies so that we can report on it in more detail. You can read more about this process here in our documentation.

[jodygarnett]

I am trying to determine this from the perspective of other others:

Q: Would using the API action to submit dependencies determined from pom minimize the number of artifacts required to be listed in security advisories?

Q: Does the maven multi module support understand war overlay.

Q: Any other projects listing installers? Is that even a useful thing to do

[jodygarnett]

To answer my question, based on discussion on #2640, the following is possible:

• manual: gs-web-core: a specific software component with the problem (something you could scan for by name and identify as being vulnerable)
• automated: gs-web-app: software distribution that includes the components, has full dependency information available on transitive dependencies

Using a workflow maven-dependency-submission-action that runs when a tag is made:

    steps:
      - name: Checkout
        uses: actions/checkout@v3
      - name: Submit Dependency Snapshot
        uses: advanced-security/maven-dependency-submission-action@v4
        with:
          directory: src/web/app
          maven-args: -Prelease

I will update the example above if I get something to work.

[mprins]

Afaik gh only supports an (one) "active" dependency graph, geosever having at times 3 active branches that produce releases with different dependencies/version will only lead to more confusion

[jodygarnett]

It seems odd to have a maven environment, and not have the tools comfortable looking up the public maven pom.xml information. The "dependency graph" is kind of the point of maven after all...