ci: Consider scanning clj-watson with clj-watson

[lread]

We should check if clj-watson deps have CVEs.
And what better way to do that than with clj-watson?

[seancorfield]

These are the CVEs that clj-watson currently reports against itself:

watson.cves.txt

[seancorfield]

I enabled --suggest-fix and most of the reported CVEs have "no secure version available" apparently, so whilst we could add a CI step to get the CVEs into the GHA output, we can't fail the build on them, and can't fix several of them.

[lread]

I've been running this over and over as my test but have not taken the time to read it!

I'll take a peek.

These seem fixable:

• org.bouncycastle/bcpg-jdk18on 1.71 (can be updated to 1.73)
• org.bouncycastle/bcprov-jdk18on 1.71 (can be updated to 1.73)
• com.h2database/h2 2.1.214 (can be updated to 2.2.220)

These all share the same: CVE-2022-4244, CVE-2022-4245

• org.codehaus.plexus/plexus-component-annotations 2.1.0
• org.codehaus.plexus/plexus-cipher 2.0
• org.codehaus.plexus/plexus-sec-dispatcher 2.0
• org.codehaus.plexus/plexus-classworlds 2.6.0
• org.codehaus.plexus/plexus-interpolation 1.26

Analyzing false-positives is a bit tortuous, but I think the plexuses (plexi?) might be false positives: jeremylong/DependencyCheck#5973, I think the CVEs are talking about plexus-utils.

• CVE-2022-4244
  As far as I understand, this one might be referring to a Redhat bundled plexus that included all plexus components.
• CVE-2022-4245

  A flaw was found in codehaus-plexus. The org.codehaus.plexus.util.xml.XmlWriterUtil#writeComment...

[seancorfield]

I've removed the milestone because I don't want us to get distracted with addressing these until we have 6.0 and 6.1 out the door.

[lread]

Sure that's fine, but TLDR: I think we won't have any unfixable vulnerabilities for clj-watson itself.