Query about new DependencyCheck dependencies

[ch-tstrickland]

When I run the Maven dependency-check plugin, it requires a couple of dependencies that we need to get into our system, one of which is:
https://mvnrepository.com/artifact/pl.project13.maven/git-commit-id-plugin/4.9.10

... which does not seem to have been updated in a while and does not seem to have a homepage.
The other:
https://github.com/kichik/pecoff4j
Does not seem to be heavily maintained.

I know that stable code often does not need to be updated. I also know that when I ask to add these dependencies to our artefact store I'm going to be asked about this, so I'm asking here. Apologies if this is the wrong forum.

When I'm asked: why are these new dependencies necessary and is it OK that they do not seem to be heavily maintained, what should I say?

[chadlwilson]

When I run the Maven dependency-check plugin, it requires a couple of dependencies that we need to get into our system, one of which is: https://mvnrepository.com/artifact/pl.project13.maven/git-commit-id-plugin/4.9.10

What is your methodology for concluding that this dependency is needed as a user? This is used when building the plugin but I do not see it in the runtime dependency tree. Perhaps I am missing something specific to the Maven plugin.

(this is off current master but should be roughly similar)

[INFO] org.owasp:dependency-check-maven:maven-plugin:12.2.2-SNAPSHOT
[INFO] +- org.owasp:dependency-check-core:jar:12.2.2-SNAPSHOT:compile
[INFO] |  +- org.anarres.jdiagnostics:jdiagnostics:jar:1.0.7:compile
[INFO] |  +- com.kichik.pecoff4j:pecoff4j:jar:0.4.1:compile
[INFO] |  +- io.github.jeremylong:jcs3-slf4j:jar:1.0.5:compile
[INFO] |  +- org.apache.commons:commons-jcs3-core:jar:3.2.1:compile
[INFO] |  +- us.springett:cpe-parser:jar:3.0.1:compile
[INFO] |  +- org.semver4j:semver4j:jar:5.8.0:compile
[INFO] |  +- org.slf4j:slf4j-api:jar:2.0.17:compile
[INFO] |  +- org.apache.commons:commons-collections4:jar:4.5.0:compile
[INFO] |  +- org.apache.commons:commons-compress:jar:1.27.1:compile
[INFO] |  |  \- commons-codec:commons-codec:jar:1.21.0:compile
[INFO] |  +- commons-io:commons-io:jar:2.21.0:compile
[INFO] |  +- org.apache.commons:commons-text:jar:1.15.0:compile
[INFO] |  +- org.apache.commons:commons-dbcp2:jar:2.14.0:compile
[INFO] |  |  +- org.apache.commons:commons-pool2:jar:2.13.0:compile
[INFO] |  |  \- jakarta.transaction:jakarta.transaction-api:jar:1.3.3:compile
[INFO] |  +- org.apache.lucene:lucene-core:jar:9.12.3:compile
[INFO] |  +- org.apache.lucene:lucene-analysis-common:jar:9.12.3:compile
[INFO] |  +- org.apache.lucene:lucene-queryparser:jar:9.12.3:compile
[INFO] |  |  +- org.apache.lucene:lucene-queries:jar:9.12.3:compile
[INFO] |  |  \- org.apache.lucene:lucene-sandbox:jar:9.12.3:compile
[INFO] |  |     \- org.apache.lucene:lucene-facet:jar:9.12.3:compile
[INFO] |  +- org.slf4j:jul-to-slf4j:jar:2.0.17:compile
[INFO] |  +- org.slf4j:jcl-over-slf4j:jar:2.0.17:compile
[INFO] |  +- org.apache.velocity:velocity-engine-core:jar:2.4.1:compile
[INFO] |  +- com.h2database:h2:jar:2.4.240:compile
[INFO] |  +- org.eclipse.parsson:jakarta.json:jar:1.1.7:compile
[INFO] |  +- org.jsoup:jsoup:jar:1.22.1:compile
[INFO] |  +- com.fasterxml.jackson.core:jackson-databind:jar:2.21.2:compile
[INFO] |  +- com.fasterxml.jackson.datatype:jackson-datatype-jsr310:jar:2.21.2:compile
[INFO] |  +- com.fasterxml.jackson.module:jackson-module-blackbird:jar:2.21.2:compile
[INFO] |  +- com.fasterxml.jackson.dataformat:jackson-dataformat-yaml:jar:2.21.2:compile
[INFO] |  |  \- org.yaml:snakeyaml:jar:2.5:compile
[INFO] |  +- com.h3xstream.retirejs:retirejs-core:jar:3.0.4:compile
[INFO] |  |  \- com.github.spullara.mustache.java:compiler:jar:0.9.6:compile
[INFO] |  +- org.sonatype.ossindex:ossindex-service-client:jar:1.8.2:compile
[INFO] |  |  \- javax.xml.bind:jaxb-api:jar:2.3.1:compile
[INFO] |  |     \- javax.activation:javax.activation-api:jar:1.2.0:compile
[INFO] |  +- com.google.code.gson:gson:jar:2.13.2:compile
[INFO] |  |  \- com.google.errorprone:error_prone_annotations:jar:2.41.0:compile
[INFO] |  +- com.google.guava:guava:jar:33.5.0-jre:compile
[INFO] |  |  \- com.google.guava:failureaccess:jar:1.0.3:compile
[INFO] |  +- com.moandjiezana.toml:toml4j:jar:0.7.2:compile
[INFO] |  +- com.hankcs:aho-corasick-double-array-trie:jar:1.2.3:compile
[INFO] |  +- commons-validator:commons-validator:jar:1.10.1:compile
[INFO] |  +- org.eclipse.packager:packager-rpm:jar:0.21.0:compile
[INFO] |  |  +- org.eclipse.packager:packager-core:jar:0.21.0:compile
[INFO] |  |  \- org.tukaani:xz:jar:1.9:compile
[INFO] |  +- org.apache.httpcomponents.core5:httpcore5:jar:5.4.2:compile
[INFO] |  +- org.apache.httpcomponents.client5:httpclient5:jar:5.6.1:compile
[INFO] |  |  \- org.apache.httpcomponents.core5:httpcore5-h2:jar:5.4:compile
[INFO] |  +- com.fasterxml.jackson.core:jackson-core:jar:2.21.2:compile
[INFO] |  +- com.fasterxml.jackson.core:jackson-annotations:jar:2.21:compile
[INFO] |  +- org.sonatype.goodies:package-url-java:jar:1.2.0:compile
[INFO] |  +- joda-time:joda-time:jar:2.14.1:compile
[INFO] |  +- org.sonatype.ossindex:ossindex-service-api:jar:1.8.2:compile
[INFO] |  |  \- javax.ws.rs:javax.ws.rs-api:jar:2.0.1:compile
[INFO] |  +- com.esotericsoftware:minlog:jar:1.3.1:compile
[INFO] |  \- org.json:json:jar:20251224:compile
[INFO] +- org.owasp:dependency-check-utils:jar:12.2.2-SNAPSHOT:compile
[INFO] +- org.apache.maven.reporting:maven-reporting-api:jar:4.0.0:compile
[INFO] +- org.apache.maven.doxia:doxia-sink-api:jar:2.1.0:compile
[INFO] +- org.apache.maven.shared:file-management:jar:3.2.0:compile
[INFO] +- org.codehaus.plexus:plexus-utils:jar:4.0.3:compile
[INFO] +- org.codehaus.plexus:plexus-xml:jar:3.0.1:compile
[INFO] +- org.apache.maven.shared:maven-dependency-tree:jar:3.3.0:compile
[INFO] +- org.apache.maven.shared:maven-artifact-transfer:jar:0.13.1:compile
[INFO] +- org.apache.maven.shared:maven-common-artifact-filters:jar:3.4.0:compile
[INFO] +- org.apache.commons:commons-lang3:jar:3.20.0:compile
[INFO] +- io.github.jeremylong:open-vulnerability-clients:jar:9.0.5:compile
[INFO] |  +- org.apache.httpcomponents.client5:httpclient5-cache:jar:5.6.1:runtime
[INFO] |  \- com.samskivert:jmustache:jar:1.16:runtime
[INFO] +- com.github.package-url:packageurl-java:jar:1.5.0:compile

... which does not seem to have been updated in a while and does not seem to have a homepage.

It should be irrelevant to users, but it seems the project was moved to a new github org and new maven coordinates at https://github.com/git-commit-id/git-commit-id-maven-plugin We'll need to migrate - but as above, shouldn't be relevant to users.

The other: https://github.com/kichik/pecoff4j Does not seem to be heavily maintained.

The change was specifically to move from a totally unmaintained to a slightly-more-maintained variant: #8245 so this is a net positive from earlier ODC versions because the very dead org.whitesource:pecoff4j was removed.

This is used for analyzing Windows binary DLLs. The library is small and low risk, and it's open source - feel free to review its source.

I know that stable code often does not need to be updated. I also know that when I ask to add these dependencies to our artefact store I'm going to be asked about this, so I'm asking here. Apologies if this is the wrong forum.

When I'm asked: why are these new dependencies necessary

I'm not quire sure what kind of response you are looking for, however the latter dependency is part of the software that you use to scan dependencies; for free. :-) This is open source, so you can review the changelog to see for what reason any dependency changes were made and make judgments as an org about the discipline and responsibility of the maintainers.

Eventually software supply chain is about trust - or at least trust-but-verify.

and is it OK that they do not seem to be heavily maintained, what should I say?

This seems like some hypothetical enterprise "security" fishing mission, and that question is a bit of a trap. If your organisation wishes to have complete piece of mind as to their entire software supply chain, to the individual dependency level with articulation as to reasonably for an entire SBOM, perhaps they are better to pay for commercially-supported software. Would love to have that for ODC myself (hence working on things like #8312), but there are only so many hours in the day to do free work companies don't pay for (and for other OSS folks and individuals, it is true).

Otherwise you explain what you mentioned above - that stable doesn't mean buggy or insecure - and that appropriately licensed open source means that if there is a need to patch software to fix an urgent issue, then anyone can fork it and do so including your own company, the maintainers here, or anyone with Internet access.

Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.

I'm not trying to be flippant - but it's a serious point - if that's not good enough for the org; considering using commercially supported software. (I'm not arguing that proprietary or closed or commercial software is actually more secure, or better quality - just that some orgs need providers that can handhold them via commercial support or they are otherwise placing burdens or expectations on open source that are expressly denied by licenses)

[ch-tstrickland]

I have to apologise, I clearly got my tone completely wrong and also mis-phrased my questions.

I love dependency-check and have pushed hard for it in my org. I certainly wasn't trying to lay a trap and was probably overthinking our processes for getting stuff added to our artefact store. You are quite right - I should have looked at the changelog properly and I agree with the other points that you have made.

Thank you for taking the time to reply at length and sorry to have put you to the bother.

[chadlwilson]

I don't think you got your tone wrong :-) But it's totally possible my tone was wrong or misinterpreted! I was more saying that enterprises/companies/govs tend to lay such a "trap" when they ask those types of questions (but I sure know I have been asked them many times, even putting away my "open source maintainer/contributor" hat). Probably means I answer more "matter of fact" than I should.

If I was putting my consulting hat on and "really" trying to convince someone of the relative trade-offs of open source as to EOL, I'd often take one of the corporate/govs "favourite" adjacent commercial products; use a tool to report on the actual software composition of said tool; then show whomever in security/corporate was asking the questions the likely many unmaintained/EOL libraries and then ask them how confident they were that said vendor would be sufficiently responsive without forcing them to pay for a large license cost to move to a new version; or needing to re-contract for 'n' years.

Can you clarify how you discovered/concluded as to the git-commit-id-plugin being added? Nothing should have changed related to this plugin. How did it even come across your radar? That would certainly not be intended if it's being exposed to users. However sometimes Maven does funny things with parent POMs and Maven plugins themselves which I might be missing.

[chadlwilson]

Also to clarify, I am just a collaborator/contributor/triager here. I am not "the" maintainer or an "official representative of the project" or any such thing.

[ch-tstrickland]

Regarding:

Can you clarify how you discovered/concluded as to the git-commit-id-plugin being added?

... a further small apology!

I have just shifted teams and am juggling a little too much, so I rushed this original post a little. When I first ran:

mvn org.owasp:dependency-check-maven:12.2.1:check

It broke, requiring pecoff4j. Later in the day, wanting to be sure I'd got all the dependencies that I could require, I had meant to run:

mvn org.owasp:dependency-check-maven:12.2.1:check -Dmaven.test.failure.ignore=true

While juggling meetings, I instead ran, from within a checked-out repo of DependencyCheck:

mvn dependency:tree -Dverbose -Dmaven.test.failure.ignore=true >/tmp/depcheck-tree

... and so came up with git-commit-id-plugin. Sorry about that.

---

If I was putting my consulting hat on and "really" trying to convince someone of the relative trade-offs of open source as to EOL, I'd often take one of the corporate/govs "favourite" adjacent commercial products; use a tool to report on the actual software composition of said tool; then show whomever in security/corporate was asking the questions the likely many unmaintained/EOL libraries and then ask them how confident they were that said vendor would be sufficiently responsive without forcing them to pay for a large license cost to move to a new version; or needing to re-contract for 'n' years.

^^^ I love this & will definitely be using it in future discussions.

[chadlwilson]

While juggling meetings, I instead ran, from within a checked-out repo of DependencyCheck:

mvn dependency:tree -Dverbose -Dmaven.test.failure.ignore=true >/tmp/depcheck-tree

... and so came up with git-commit-id-plugin. Sorry about that.

Hmm, does that imply your own build is using git-commit-id-plugin, or you were running dependency:tree on a clone of this repository for your investigation?

[ch-tstrickland]

A clone of this repo for investigation, hanging around from earlier an investigation of another feature.

[marcelstoer]

It seems #8444 (migrating the Git commit ID plugin) was triggered by this discussion.

@ch-tstrickland Anything else that needs discussing or can this be closed now?

[chadlwilson]

I think it's OK - good from my perspective :-)

[ch-tstrickland]

All good from my perspective. Thank you all for a superb tool.