Add support to validate sbom is valid before publish

[zdtsw]

To ensure sbom.json we release is valid by cyclonedx, we can use cyclonedx-cli to validate in our build system.

another option is https://github.com/IBM/sbom-utility

Part of #3013

[zdtsw]

some thoughts for what we can implement:

1. install cli tool onto our build machines (since this is a post step we do not need to have it on the container which we build code)
2. setup a adoptium sbom webserver so we can use its API to valid -- i would prefer they have REST towards their official one, but no....
3. have the validation in the step of smoke test(?) so we do not gate the pipeline for testing -- this requires install cli on to VM + docker image as well. coz test share the same agents as build.
4. use "docker run cyclonedx/cyclonedx-cli"

[andrew-m-leonard]

@julian55455

1. I suggest first get an understanding of the cli tool: https://github.com/CycloneDX/cyclonedx-cli
2. As @zdtsw suggested adding this to the SmokeTest probably makes sense: https://github.com/adoptium/temurin-build/blob/master/test/functional/buildAndPackage/playlist.xml
3. From what you've learned investigating 1 & 2, create a plan of how to move forward, are there any blocking issues? or difficulties?
4. Review plan with mentors
5. Implement plan

[julian55455]

@zdtsw @smlambert @andrew-m-leonard @sxa

1. I have created SBOMTest.java class which am planning to send a pull request for here then add to the smoke test here
2. How to get Cyclonedx Cli on the build machines seems to be the issue (for now)
3. Not so familiar with the adoptium infrastructure and am wondering whether we are going to test against the production servers if not so, can we probably have some kind of an established remote server where we could make builds and test from?
4. From this blog, it looks like it might be possible to set up local dev env(not so certain though). If so, is it possible to have the sever configurations to the local dev env so that we test agansit the existing variables?

I need advice am probably assuming the impossible

[smlambert]

There are several ways to get CycloneDX onto the test machines during a smoke test, and I think we should explore the pros and cons of these options:

1. pull the CycloneDX source code in and build it as part of the compile stage of the test
2. pull a prebuilt platform-specific binaries in as part of the compile stage of the test
3. spin up the CycloneDX CLI Docker image as part of the test (needs to run on nodes with sw.tool.docker label)

Mentioned in Slack thread, there are many examples of other tests that setup dependencies in their build.xml (ant script) file (both pre-built and source code examples). If we do 1 or 2, we add a new ant target in https://github.com/adoptium/temurin-build/blob/master/test/functional/buildAndPackage/build.xml, perhaps called getCyclonedxCli that either git clone's and builds it, or calls curl command to fetch a prebuilt binary.

[smlambert]

Ok, from various Slack discussions

• there are barriers to option 1 (particularly due to the dotnet prereqs needed to build this tool)
• option 2 is still a possibility, but may not be preferred over option 3
• option 3, docker run cyclonedx/cyclonedx-cli validate --input-file sbom.json as part of a smoke test should be explored as a preferred option

We also want to create a diagram of the workflow we expect to create, and discuss how the SBOMTest can be extended to test other aspects of the SBOM. I will add some diagrams shortly, to initiate discussion.

[zdtsw]

Just to make it more clear (since there is some misunderstanding of which sub-command should be used in the context of this issue):
we should use "validate" not "verify" for the cyclonedx-cli.

These two are doing different operations on sbom.
Due to the fact that we need to wait for v1.5 to have schema well defined, we do not sign our sbom yet we are not ready to use "verify" for the moment.

[smlambert]

We actually do sign the SBOM (described in #3158 (comment)), just not in the way that we want to (preferred way described in #3158 (comment)).

But as mentioned in a private Slack chat, I suspect that SBOMTest will eventually have more checks inside of it (much like other smoke tests have more than one test method within them):
check 1: validate the sbom is well-formed <-- this is our focus
check 2: verify signatures ? (likely not needed as an explicit check, since it is an implicit action to be able to do check 1)
check 3: analyze the content of the file, and warn if anything listed in the sbom is 'at risk' <-- this is a big item and may not be part of the Outreachy term, since there are other higher priority tasks in the list

[smlambert]

For SBOM Test, we can first create it as a standalone test (that can be run from a Grinder job in Jenkins), then we can later incorporate it into the build pipeline (via a Post-build job, shown in the following diagram as Task 1 and relating to adoptium/ci-jenkins-pipelines#548).

[julian55455]

@smlambert can I take up this?

[julian55455]

option 3, docker run cyclonedx/cyclonedx-cli validate --input-file sbom.json as part of a smoke test should be explored as a preferred option

@smlambert , how are we planning to finish up with this?

[smlambert]

hi @julian55455 ! We can pick up it up from here. I have the learnings from your branch and will plan to create a fresh branch to run the test. Thanks for all of your investigation and learnings on this topic!

[julian55455]

hi @julian55455 ! We can pick up it up from here. I have the learnings from your branch and will plan to create a fresh branch to run the test. Thanks for all of your investigation and learnings on this topic!

@smlambert Great, Just incase there is need for help, Am in