Security Scan Warning - JSOUP...?

[paulbandler]

Using htmlflow raises a couple of potential security issues.

A 'Medium' severity indicates that an upgrade to version 1.15.3 of the jsoup dependency is needed:

  org.jsoup:jsoup 1.14.2
  hierarchy: 
    testutils:dataignition-thfw:--
      core:core-framework:--
        com.github.xmlet:htmlflow:3.9
          org.jsoup:jsoup:1.14.2
  advisories:
    -> severity:  MEDIUM 
       CVSS: 6.1, EPSS: 39.51%
       info: https://nvd.nist.gov/vuln/detail/CVE-2022-36033
       jsoup is a Java HTML parser, built for HTML editing, cleaning, scraping, and cross-site scripting (XSS) safety. jsoup may incorrectly sanitize HTML including `javascript:` URL expressions, which could allow X
       SS attacks when a reader subsequently clicks that link. If the non-default `SafeList.preserveRelativeLinks` option is enabled, HTML including `javascript:` URLs that have been crafted with control characters
       will not be sanitized. If the site that this HTML is published on does not set a Content Security Policy, an XSS attack is then possible. This issue is patched in jsoup 1.15.3. Users should upgrade to this ve
       rsion. Additionally, as the unsanitized input may have been persisted, old content should be cleaned again using the updated version. To remediate this issue without immediately upgrading: - disable `SafeList
       .preserveRelativeLinks`, which will rewrite input URLs as absolute URLs - ensure an appropriate [Content Security Policy](https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP) is defined. (This should be use
       d regardless of upgrading, as a defence-in-depth best practice.)

A further low severity issue arises from guava, included below fyi, but it indicates that the issue can be mitigated by appropriate local admin steps:

  com.google.guava:guava 30.0-jre
  hierarchy:
    testutils:dataignition-thfw:--
      core:core-framework:--
        com.github.xmlet:htmlflow:3.9
          com.github.xmlet:htmlApiFaster:1.0.9
            org.jboss.windup.decompiler:decompiler-fernflower:4.0.0.Final
              org.jboss.windup.utils:windup-utils:4.0.0.Final
                com.google.guava:guava:30.0-jre
  advisories:
    -> severity:  LOW
       CVSS: 3.3, EPSS: 74.38%
       info: https://nvd.nist.gov/vuln/detail/CVE-2020-8908
       A temp directory creation vulnerability exists in all versions of Guava, allowing an attacker with access to the machine to potentially access data in a temporary directory created by the Guava API com.google
       .common.io.Files.createTempDir(). By default, on unix-like systems, the created directory is world-readable (readable by an attacker with access to the system). The method in question has been marked @Depreca
       ted in versions 30.0 and later and should not be used. For Android developers, we recommend choosing a temporary directory API provided by Android, such as context.getCacheDir(). For other Java developers, we
       recommend migrating to the Java 7 API java.nio.file.Files.createTempDirectory() which explicitly configures permissions of 700, or configuring the Java runtime's java.io.tmpdir system property to point to a
       location whose permissions are appropriately configured.

[fmcarvalho]

DONE release 4.0