docs: adding ADR for selection of trivy for the keycloak pipeline

[idunbarh]

1. Sbom Generation Tool Selection

Date: 2024-08-09

Status

Proposed

Context

What is the issue that we're seeing that is motivating this decision or change?

For phase 1, the Tiger Team selected keycloak as a java open source project to create a SBOM for. Since different ecosystems have different support by different tools, we did an un-official trade study of different SBOM generation tools to decide what was best to use for this first project.

Decision

What is the change that we're proposing and/or doing?

The tiger team is proposing we use trivy and analyze source of the keycloak project.

• Un-official Trade Study

This decision is based on the following factors:

• Analysis of the components discovered in comparison of other tools
• Ability to generate both CycloneDX and SPDX SBOMs
• Completness of the depenency graph
• Compliance with the NTIA Minimum Elements

Honorable Mentions

Syft

Syft met most of the requirements but ultimated decided against for three reasons.

• Number of duplicate components
  • We found Syft generated a lot of duplicate componets in the sbom which increases it size and complexity without adding value
• Source code scanning maven build variables
  • Some build variables for component names were not expanded resulting in variable names being used for component identification
• Jar scanning dependency graph incomplete
  • Syft Jar scanning added hashes to the sboms, but lacked the dependency graph information

cyclonedx-maven-plugin

cyclonedx-maven-plugin definitely produced the best "per component" completeness of the NTIA Minimum Elements, but was decided against for two reasons.

• No SPDX Support
  • A requirement for this tiger team is to support both major SBOM formats. cyclonedx-maven-plugin only supports CycloneDX
• Needs to be added to all project pom.xml files
  • We want to avoid directly modifying the configuration files of Keycloak

:note: If you only need CycloneDX sboms for a java project, we'd recommend teams investigate this tool.

Consequences

What becomes easier or more difficult to do because of this change?

Some information will be harder to enrich later in the SBOM Generation Pipeline.

Specifically:

• hashes

[aloubyansky]

Given that SBOMs allow recording all sorts of data. Form the content perspective, what are the ultimate requirements for the produced SBOMs? For example: A list of components? Build time and/or runtime dependencies? License info? Recording of dependency graphs? Build tools info? Other?

Thanks.

[idunbarh]

Given that SBOMs allow recording all sorts of data. Form the content perspective, what are the ultimate requirements for the produced SBOMs? For example: A list of components? Build time and/or runtime dependencies? License info? Recording of dependency graphs? Build tools info? Other?

Thanks.

We'll be using a whitepaper from a different CISA tiger team to define "completeness".

• Framing Software Component Transparency Third Edition (DRAFT)

The level of completeness that can be achieved will be based on the best open source tooling available which can support multiple SBOM formats. The same is true for validating completeness.