Metadata filtering for tool in sbom

[lislei]

Hello Steve Springett.

I noticed the gradle plugin didn't fill inn the metadata of the tool producing the SBOM.

This pull request adds filtering capability to the gradle build.
Also, the commons-io dependency is replaced with use of the standard JDK-api.

I've successfully verified the contents of the property file as well as outputted XML and JSON files.
This produces similar data as what the maven plugin does.

What I'm uncertain of is the format of the value for "timestamp" as it is left unexpanded by the maven plugin.
The SBOM 1.4 schema doesn't specify this explicitly.
Is this field unused and to be removed or should it be formatted in a certain way?

[lislei]

My test produced this XML

  <metadata>
    <timestamp>2022-02-10T16:25:56Z</timestamp>
    <tools>
      <tool>
        <vendor>CycloneDX</vendor>
        <name>CycloneDX Gradle plugin</name>
        <version>1.5.0-SNAPSHOT</version>
      </tool>
    </tools>

.. and the content of the plugin property file is:

# Automatically populated by Gradle build - do not modify
vendor=CycloneDX
name=CycloneDX Gradle plugin
version=1.5.0-SNAPSHOT
timestamp=1644510352444

[sonatype-lift]

Severe OSS Vulnerability:

pkg:maven/org.apache.maven/[email protected]

0 Critical, 1 Severe, 1 Moderate, 0 Unknown vulnerabilities have been found across 1 dependencies

Components

pkg:maven/com.google.guava/[email protected]

SEVERE Vulnerabilities (1)




[CVE-2018-10237] Deserialization of Untrusted Data

Unbounded memory allocation in Google Guava 11.0 through 24.x before 24.1.1 allows remote attackers to conduct denial of service attacks against servers that depend on this library and deserialize attacker-provided data, because the AtomicDoubleArray class (when serialized with Java serialization) and the CompoundOrdering class (when serialized with GWT serialization) perform eager allocation without appropriate checks on what a client has sent and whether the data size is reasonable.

CVSS Score: 5.9

CVSS Vector: CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H

MODERATE Vulnerabilities (1)




[CVE-2020-8908] A temp directory creation vulnerability exists in all versions of Guava, allowin...

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 @deprecated 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.

CVSS Score: 3.3

CVSS Vector: CVSS:3.0/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N

(at-me [in a reply](https://help.sonatype.com/lift/talking-to-lift) with `help` or `ignore`)