This is a bit tricky, because now trivy can generate two different kinds
of scan results, normal trivy-json results and sbom-cyclonedx results.
To keep these parsers separated, an additional CycloneDX parser is
added. To not overcomplicate the structure, this parser is added in the
trivy scanner directory. If in the future there are multiple scanners
creating SBOMs, it can be moved somewhere else.

Adding a second parser for a scanner requires some Makefile trickery.
Usually the docker-build, docker-export, kind-import and deploy Makefile
targets are used to build and deploy a scanner. Adapting the first three
targets is easy, the additional parser just needs an extra build step
wich can be added as another dependency. The deploy is more tricky
because it is a single helm upgrade --install command, which sets the
necessary values for docker repository and tag. This is achieved by
redefining the Makefile target, but it is not the nicest solution, make
warns about the target getting overridden.

The parser is a generic cyclonedx parser (although with currently
limited functionality), but currently lives in the trivy scanner
directory because it is only used here and means the global structure
does not have to get changed. Because it is not trivy-specific, it is
not supposed to use "trivy" in its name/repository. This means, the
common-... Makefile targets cannot always be used, and if they can, they
have to be used in unintended ways. By default they get used by setting
the module variable to the directory name of what is built and then add
the name of the scanner in the end, for example the parser for trivy
ends up being built as parser-trivy from the parser directory. Now to
prevent the CycloneDX parser getting named parser-cyclonedx-trivy, the
docker-build-cyclonedx-parser target cannot use the common-docker-build
and the export/import targets have to be a bit creative with using the
module and name variables. This might get reworked to make the Makefiles
nicer again.

Signed-off-by: Lukas Fischer <[email protected]>

Basic functionality of a persistence hook, that sends CycloneDX SBOMs to
OWASP Dependency-Track. Since hooks run for all scans, the hook first
checks the scanType and then the bomFormat property to see if the
rawResult is actually a CycloneDX SBOM. If it is it gets uploaded to
Dependency-Track.

To assign an SBOM to a project, either the project UUID or the name and
version are required. The hook tries to grab the name and version from
the name property of the SBOM and automatically creates missing
projects. This is not the nicest way to get name and version, but there
is no better property in the SBOM to read it from. It works for
container scans, but probably breaks for other kinds of SBOM scans.

Signed-off-by: Lukas Fischer <[email protected]>

Expand the comments in the trivy Makefile to explain more in detail why
the changes are necessary to build the the CycloneDX parser as well.

Signed-off-by: Lukas Fischer <[email protected]>

Make sure the persistence-dependencytrack hook can be tested
automatically by providing some tests for it. Some parts of the tests
might be coupled a bit tightly to the actual implementation, if the
endpoint is switched to the PUT endpoint the tests will have to be
adapted.

The tests inject the mocked dependencies through parameters, similar to
how the tests for the generic webhook work. Since fetch() is the only
dependency here, this works pretty well.

Signed-off-by: Lukas Fischer <[email protected]>

Add a small and very simple test for the CycloneDX parser, after all it
doesn't do much. More annoying is again the Makefile structure, since
the project is not set up for multiple parsers for a scanner, it also
does not accommodate that for the tests. To circumvent this, the added
target for the parser-cyclonedx tests needs to manually run the
install-deps-js target with a different module name, so that all the
dependencies get installed correctly.

Signed-off-by: Lukas Fischer <[email protected]>

Keeping SBOM creation as part of the original trivy scanner created a
whole bunch of problems, all related to the fact that we decided that
SBOMs should get their own parser instead of reusing the existing trivy
parser. Since nothing in the project structure assumes that scanners can
have more than one parser, making the Makefile targets work with it was
pretty inconvenient. The release process, orchestrated by a GitHub
Workflow, also cannot work with multiple parsers.

This extracts all SBOM related functionality from the trivy scanner to a
new trivy-sbom scanner, which then works again with the usual project
structure. The parser is still a generic CycloneDX parser, although
adding Syft and then reusing the parser needs resturcturing again (or
copy-pasting of code).

Signed-off-by: Lukas Fischer <[email protected]>

MAke sure the parser properly reads an actual trivy-generated CycloneDX
SBOM file.

Signed-off-by: Lukas Fischer <[email protected]>

Signed-off-by: Lukas Fischer <[email protected]>

Releases and CI only partially use makefiles. To make sure the
trivy-sbom scanner and the persistence-dependencytrack hook are included
in all builds, they are added to the corresponding matrix lists here.

Signed-off-by: Lukas Fischer <[email protected]>

Make sure that people can more easily combine the Trivy SBOM scanner
with the Dependency-Track hook by linking eachother from their
documentation.

Use absolute links to make sure that external links from GitHub,
DockerHub and ArtifactHub also work. See secureCodeBox#1963

Signed-off-by: Lukas Fischer <[email protected]>

Instead of just crashing hard, check the response the Dependency-Track
API returns for network errors and error status codes to print nicer
error messages.

Signed-off-by: Lukas Fischer <[email protected]>

The previous way of detecting the name and version to supply to
Dependency-Track was very brittle, it already failed for image
references including a hash, resulting in names like hello-world@sha256,
because it would only split on ':' and then select the first and last
component.

This version uses a regex to as accurately as possible match the
individual components of a docker image reference. The regex comes from
the [official implementation] on GitHub, but is actually taken from a
[pull request], which adds named capture groups and fixes an issue with
domain recognition being too eager.

Yes the regex looks pretty wild, yes there are tests. I don't think it
makes sense to build the regex from the individual components like the
docker library does it.

Unfortunately this does not solve the problem of actually getting the
reference from somewhere, for images it works with getting it from the
name of the main component, but this part stays brittle. Annotations to
the scans might be a possible solution for that.

[official implementation]: https://github.com/distribution/reference
[pull request]: distribution/distribution#3803

Signed-off-by: Lukas Fischer <[email protected]>