Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

How to scan plugins in the maven <build><plugins>.... section #4035

Closed
chtpl opened this issue Feb 1, 2022 · 8 comments
Closed

How to scan plugins in the maven <build><plugins>.... section #4035

chtpl opened this issue Feb 1, 2022 · 8 comments

Comments

@chtpl
Copy link

chtpl commented Feb 1, 2022

I accidentally had added

<groupId>pl.project13.maven</groupId>
<artifactId>git-commit-id-plugin</artifactId>
<version>4.0.4</version>

to the section of my POM
I also had it correctly in the build plugins section.

Scanning with dependency check maven plugin showed some vulnerabilities for plexus 2.0.4 which was shown as dependency of git-commit-id-plugin when executing mvn dependency:tree

When I removed the dependency git-commit-id-plugin from the regular dependencies block, the finding in dependency check had gone away.
Is there a way I can include all dependencies from the POM in the dependency check? Even during build and packaging time I think it's important to not have any vulnerable code included in the project

@chtpl chtpl added the question label Feb 1, 2022
@jeremylong
Copy link
Owner

Currently no - ODC does not scan the plugins or plugins management. The only quick idea I would have is to make a profile called plugin-scan and simple copy the dependency-management section into the dependencies in the profile.

@CasperNLD
Copy link

As via an other issue, I hereby would like to ask to make an enhancement in the plugin, so it can check for problems in the plugins in a build (and a build of a profile).

@jeremylong
Copy link
Owner

@aikebah I started implementing the ability to scan the Maven plugins and would like your opinion on a few things: https://github.com/jeremylong/DependencyCheck/compare/plugins

  1. Added Dependency#includedBy as a place to store a reference to the "parent" dependency/plugin.
    a. Should this be called childOf instead?
    b. Given the standard CheckMojo - could we enhance the processing to include the parent/root dependency of the dependency chain for transitive dependencies?
  2. This was created as a separate mojo so dependencies from the plugins do not get mixed with dependencies of the application. This might be solvable if we can complete 1b... Another reason we may want to fold this into the existing Mojos are discussions in the CycloneDx space (SBOM): Add formulation support CycloneDX/specification#31

In addition to the above - any other feedback is welcome.

@aikebah
Copy link
Collaborator

aikebah commented Oct 24, 2022

@aikebah I started implementing the ability to scan the Maven plugins and would like your opinion on a few things: https://github.com/jeremylong/DependencyCheck/compare/plugins

@jeremylong thanks for pinging me on this one early in the process.

  1. Added Dependency#includedBy as a place to store a reference to the "parent" dependency/plugin.
    a. Should this be called childOf instead?

For now I think includedBy the better choice. For childOf I would expect only direct childs (direct dependencies of the plugin) to hold a reference to the plugin that depend on it.

b. Given the standard CheckMojo - could we enhance the processing to include the parent/root dependency of the dependency chain for transitive dependencies?

Getting the full graph properly sorted out might require a lot of duplicate code to be written. From memory last time I checked the transitive dependency resolution (the internal dependency graph) was an internal aspect of maven, not exposed on its shared APIs. Only the combined direct+transitive dependencyset was exposed as a project's dependencies.
But maybe with the reintroduction of the verbose dependency tree https://issues.apache.org/jira/browse/MDEP-644 things have changed in that respect.

  1. This was created as a separate mojo so dependencies from the plugins do not get mixed with dependencies of the application. This might be solvable if we can complete 1b... Another reason we may want to fold this into the existing Mojos are discussions in the CycloneDx space (SBOM): Add formulation support CycloneDX/specification#31

In addition to the above - any other feedback is welcome.

I think in the end we want to merge the two indeed (and make it a configuration properties of the check/aggregate mojos whether to include pluginManagement, plugins and extensions).

But I can imagine it might be better to first get this stable and tested as a separate mojo.

Also note that for plugins we need to include the dependencies added as additional plugin dependencies in the project pom file (or one of its parents). I don't think those are accounted for in the base artifactresolver logic. https://maven.apache.org/pom.html#Plugins

Also we should not forget that also extensions can be added at the plugin level (in addition to the ones added at the project level)

I'll dive a bit deeper when I can find some time to spend on it and may offer further advice or remarks. First item on my todo is to review your PR for the known exploited vulnerabilities which I also consider a valuable addition.

@jeremylong
Copy link
Owner

@aikebah I updated the plugins branch and folded the plugin scanning into the check and aggregate mojo. So we don't loose track of which came from the dependencies and plugins - I ended up adding the includedBy to the dependencies as well.

@jeremylong
Copy link
Owner

This is the main thing holding up the 8.0.0 release - specifically I'm working on the gradle version to scan the build environment.

@OrangeDog
Copy link
Contributor

Do maven plugins (unlike projects) all have independent dependencies, or is there an issue with resolving what's actually used?

maven-compat-3.0.jar (pkg:maven/org.apache.maven/maven-compat@3.0) : CVE-2021-26291
maven-compat-3.1.1.jar (pkg:maven/org.apache.maven/maven-compat@3.1.1) : CVE-2021-26291
maven-core-2.2.1.jar (pkg:maven/org.apache.maven/maven-core@2.2.1, cpe:2.3:a:apache:maven:2.2.1:*:*:*:*:*:*:*) : CVE-2021-26291
maven-core-3.0.5.jar (pkg:maven/org.apache.maven/maven-core@3.0.5, cpe:2.3:a:apache:maven:3.0.5:*:*:*:*:*:*:*) : CVE-2021-26291
maven-core-3.0.jar (pkg:maven/org.apache.maven/maven-core@3.0, cpe:2.3:a:apache:maven:3.0:*:*:*:*:*:*:*) : CVE-2021-26291
maven-core-3.1.0.jar (pkg:maven/org.apache.maven/maven-core@3.1.0, cpe:2.3:a:apache:maven:3.1.0:*:*:*:*:*:*:*) : CVE-2021-26291
maven-core-3.1.1.jar (pkg:maven/org.apache.maven/maven-core@3.1.1, cpe:2.3:a:apache:maven:3.1.1:*:*:*:*:*:*:*) : CVE-2021-26291
maven-settings-3.0.5.jar (pkg:maven/org.apache.maven/maven-settings@3.0.5) : CVE-2021-26291
maven-settings-3.0.jar (pkg:maven/org.apache.maven/maven-settings@3.0) : CVE-2021-26291
maven-settings-3.1.0.jar (pkg:maven/org.apache.maven/maven-settings@3.1.0) : CVE-2021-26291
maven-settings-3.1.1.jar (pkg:maven/org.apache.maven/maven-settings@3.1.1) : CVE-2021-26291

Especially for these ones, wouldn't they all actually use the version of Maven that you're using?

@jeremylong
Copy link
Owner

Run mvn dependency:resolve-plugins and you'll see a similar list containing some of the core dependencies multiple times.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants