Introduce OWASP Dependency Check using dependency-check-maven plugin

i’ve introduces the plugin in general for all wcm.io modules (not enabled by default) in

and activated it for the caconfig editor (after cleaning up it’s dependencies a bit):

with this it’s easy to activate it for further modules later.

Transitive dependencies are indeed an issue with unit testing when using “provided” scope. I don’t have a better solution, though. I think none of the other dependency elements ( ) can be leveraged to distinguish between dependencies which are embedded/internalized vs. dependencies which are referenced externally.

Still I would argue that provided is semantically the right scope (although it is not transitive). The reference at talks about Servlet API which has a similar limitations when it comes to testing. That dependency also need to be explicitly referenced by consumer even if only used in transitive code of unit tests…

Maven is probably lacking a provided scope which still is transitive (https://issues.apache.org/jira/browse/MNG-2205)

for 1: good point it’s stored in maven repo, than we should have the proper caching rules already in place

for 2: for example in

the point is, we have always some compile dependencies for 3rdparty bundles that ship with AEM that are not part of the uber JAR/aem-sdk JAR. defined those with compile scope this is not required for OSGi, but important for unit testing. if we would set those dependencies only to “provided” users that use those bundles in their projects would need to add the dependencies themselves with test scope for unit test involving those bundles. maybe the actual project listed above has some dependencies we can get rid off after raising the min. AEM version to 6.4, but still i assume there will be some leftovers we need to suppress manually as we only compile against them, but not actually ship them.

1. We only run those checks in CI builds (with dedicated Maven profiles). For GitHub actions you can leverage https://docs.github.com/en/actions/guides/caching-dependencies-to-speed-up-workflows as the database is stored in the Maven repository.

2. As long as every dependency which is provided by AEM at runtime is referenced as “provided” this works fine. We use it in projects which import as well. Do you have some examples of dependencies being reported which are not embedded?

this is a good idea and played around with it a bit in a branch, i have some detail questions about the best way to integrate it:

1. the first run with it takes very long time, it seems a local database with signatures to check against is build up. further runs are much faster. how does this work out in CI builds e.g. in github actions? do we need to apply special caching rules to not delay every CI build by a long time?

2. even when excluding provided and runtime scope we get lots of vulnerability reports about outdated sling, commons etc. dependencies we compile against (because we are compatible down to AEM 6.4), but which are never used at runtime with a properly set up AEM instance. do we have to exclude those all manually (it’s a long list), do you have a recommendation?