-
-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
Comments
Currently no - ODC does not scan the plugins or plugins management. The only quick idea I would have is to make a profile called |
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). |
@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
In addition to the above - any other feedback is welcome. |
@jeremylong thanks for pinging me on this one early in the process.
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.
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.
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. |
@aikebah I updated the |
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. |
Do maven plugins (unlike projects) all have independent dependencies, or is there an issue with resolving what's actually used?
Especially for these ones, wouldn't they all actually use the version of Maven that you're using? |
Run |
I accidentally had added
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
The text was updated successfully, but these errors were encountered: