Provide validation of the SBOM content

[sxa]

We have lots of information in our SBOM. As part of SLSA verification requirements we should ensure that as much as possible of the data is validated including checking that the fields with information we populate about the build look "reasonable" and include checking versions of some of the prerequisites and validate that the github SHAs listed are valid.

FYI @andrew-m-leonard @netomi as this came out of the conversation we had a few weeks ago. My first pass of a validation script that does some validation on our nightly JDK17 versions is
validateSBOMcontent.sh.txt - this is very much an initial prototype (and is not currently in git until we decide on a suitable location for it) and will need to be enhanced to ensure that it can handle the correct checks for all of our openjdk versions and probably other checks.

At the moment it checks the GLIBC/GCC and ALSA versions against "expected" versions as well as validating that the GIT shas for the openjdk codebase and temurin-build are present in the corresponding repositories. All suggestions for further checks welcome. Note that this will not currently validate the last GA versions as they have a number of omissions (e.g. no GLIBC etc.) so this can only be reasonably used against the nightly builds at present.

I have been prototyping this by running it as part of a longer build download verification process that validates all the GPG signatures etc. and does other integrity checks on the downloads, so this issue purely covers validation of the SBOM content.

We can also look at CycloneDX's format validator to check that the overall format of the file is as per the CycloneDX specification.

[netomi]

ty for the link. I have checked the CycloneDX cli tool and tested it on one of the sbom files. It validates with success while its not clear what happens under the hood.

[netomi]

btw. for the notarization service I have worked on generating slsa provenance files and a script to download and verify releases:

https://github.com/eclipse-cbi/macos-notarization-service/blob/main/.github/workflows/release.yml
https://gitlab.eclipse.org/eclipsefdn/security/scripts/-/blob/main/github/download-github-release.sh?ref_type=heads

Test artifacts are available here:

https://github.com/OtterdogTest/macos-notarization-service/releases/tag/v1.2.0

Maybe a good reference for comparison.

[sxa]

The IVT job is currently working reasonably well, although without a GA build after the GCC/GLIB fix went in we cannot run this against a GA build. I have put in some fixes to allow it to work with a non-GA build including skipping the verification of the temurin-build SHA since that cannot be easily verified with the current approach unless it was a tagged commit.

This testing has also highlighted the absence of the FreeType version information in the case where the FreeType code is not downloaded - #3493 has been raised to address this.

At the moment the code is in an SXAIVT job on the Eclipse Jenkins server and it performs some of the work itself and calls validateSBOMcontent.sh.txt to check the contents of the SBOM file - this will of course be put under source control.

ty for the link. I have checked the CycloneDX cli tool and tested it on one of the sbom files.

When I saw this I managed to make sure that was integrated into my checks to and it works well as you say - thanks. I'll aim to see what I can do with the other links you've given :-)

[sxa]

Going to skip the explicit freetype check for now in the basis of the large number of inconsistent versions discovered in #3504 (comment) - will reinstate when that is resolved.
I might try and make sure it's either "N.A." or a real version (regalrdless of what it is) for now

[sxa]

I've got the verification now running successfully for all tested fields. It currently runs on a Linux machine and does a series of checks. It does not verify signatures on Windows or Mac builds, but I feel that after some issues we have experienced in the October 2023 release cycle (adoptium/ci-jenkins-pipelines#831, adoptium/ci-jenkins-pipelines#832, adoptium/temurin#4 (comment)) that will be a requirement going forward, potentially building on the work from @netomi above and/or as part of #3494.

I think I'm probably right in saying that it won't be possible to do that well enough within the job that is running on Linux so we'll need something alongside my existing processes.

[netomi]

List of related tickets:

• [SBOM] Attestation is missing a subject with digest #3528
• [SBOM] Add information about the job that generated the attested artifacts #3533
• [SBOM] Add information about the build environment / runner #3534
• [SBOM] Capture all tools with their version / digest that are downloaded during a build #3535

I would consider #3528 to be mandatory for claiming any SLSA level, the remaining are optional to further improve our attestation imho.

Something that we do not capture yet (and its not mentioned in the general SLSA requirements) is that we identify in our attestation by which builder this attestation has been produced. The intoto format declares that the builder is mandatory, but that lies in the nature of the format as it is intended to be used by tools for automatic validation purposes. In the case of Eclipse Temurin we use a highly customized format where the builder is implicitly assumed from the format, so I would expect that it would be ok to omit an identification of the builder itself in our specific case.

[sxa]

Bumping back to earlier plan as this was completed in the middle of December.