Open zdtsw opened 2 years ago
some thoughts for what we can implement:
@julian55455
@zdtsw @smlambert @andrew-m-leonard @sxa
I need advice am probably assuming the impossible
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:
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.
Ok, from various Slack discussions
docker run cyclonedx/cyclonedx-cli validate --input-file sbom.json
as part of a smoke test should be explored as a preferred optionWe 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.
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.
We actually do sign the SBOM (described in https://github.com/adoptium/temurin-build/issues/3158#issuecomment-1320327620), just not in the way that we want to (preferred way described in https://github.com/adoptium/temurin-build/issues/3158#issuecomment-1326699625).
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
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 https://github.com/adoptium/ci-jenkins-pipelines/issues/548).
@smlambert can I take up this?
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?
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!
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
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 https://github.com/adoptium/temurin-build/issues/3013