Discuss Temurin SBOM format and content

[andrew-m-leonard]

Temurin builds are now producing SBOM artifacts, eg. https://github.com/adoptium/temurin18-binaries/releases/download/jdk18u-2022-06-30-09-20-beta/OpenJDK18U-sbom_x64_linux_hotspot_2022-06-29-23-30.json

These are based upon the CycloneDX schema : https://cyclonedx.org/capabilities/

This issue is to discuss the future format and content.

[zdtsw]

Ref: https://github.com/adoptium/temurin-build/issues/3011

[zdtsw]

related https://github.com/adoptium/temurin-build/issues/2984

[zdtsw]

update with new example of sbom: https://github.com/adoptium/temurin18-binaries/releases/download/jdk18u-2022-07-02-07-33-beta/OpenJDK18U-sbom_x64_linux_hotspot_2022-07-01-23-30.json after content is updated for valiation.

[steelhead31]

I've now produced an outline spreadsheet of some of the more common Linux based distributions on docker/vm , with the content of relevant files, to help identify which detail(s) we'd like to capture in the SBOM ( Issue #3010 )

https://docs.google.com/spreadsheets/d/1a07f2QqfpmWW0EMShscsnNNDaP4TEJHy61owUW5atW0/edit#gid=0

[smlambert]

re: https://github.com/adoptium/temurin-build/issues/3013#issuecomment-1177555468 - thanks @steelhead31, it is very helpful to see all of the variants laid out in the spreadsheet

[steelhead31]

Looks like the solution will be to just change the O/S full ver to be a combination of the pretty name, and the kernel version ( which should be all relevant from a reproducibility and security perspective.. )

[zdtsw]

ref: add build path length for macos

[zdtsw]

I looked a bit how the others generate their sbom, feels like the work we are doing for getting strace information, which can be the part of components (each line of result.txt as one entry)

{
      "bom-ref": "/bin/cat",
      "type": "application",
      "name": "cat",
      "scope": "required",
      "hashes": [
        {
          "alg": "SHA-256",
          "content": "51f665b9ef41b64340585164d5f75142a268f84f9a2537cd205c2b59bcbefbea"
        }
      ],
    },
...

then each in the components has a ref to be defined as dependencies

 {
      "ref": "/bin/cat",
      "dependsOn": [
         "busybox-1.34.1-r7"
      ]
    },
...

the current content OpenJDK18U-sbom_x64_linux_hotspot_18.0.2_9.txt we have as metadata.tools["ALSA", "FreeTpye", "FreeMarker"] should be in components if is used, or not show it in the sbom metadata.tools."Docker image SHA1" should be in metadata.properties if the build is running inside a container

[zdtsw]

Post on slack https://cyclonedx.slack.com/archives/CV062H2GH/p1660811431368709

in short: CDX ( short of cyclonedx) plan to include formulation which is defined in owasp in their 1.5 release but it has not decided the date more like in the early/mid of 2023. Formulation describes how components were built often including build system invocation and properties, SDK and compiler versions, compiler flags, and a comprehensive list of parallel and sequential steps that were taken to build, test, and deliver a component. Formulation and pedigree are complimentary concepts and are often combined and referred simply as pedigree this feels like what exactly we are after. the uncertainty is, if any new tools to generate formulation from CDX 1.5 can be directly used by us? or we cannot wait for a year till 1.5 to include such because sbom will be used as input for reproducible ( in that case, we might become contributor to CDX? )

[andrew-m-leonard]

CDX formulation sounds interesting. I would guess given very few others are formulating native C/C++ SBOM's we would probably be the contributor to that work... So probably in our best interest to progress with what we're researching currently and see where it goes in a view to CDX contribution.

[sxa]

Noting that zlib is a potential source of differences and we should look at what we do with those options as they are currently inconsistent between platforms and versions in terms of whether it uses bundled or system zlib. Should we override to be consistent?

Summary:

• AIX: system on jdk11, bundled elsewhere (!) (Yes, even on same machine - test-2)
• Windows: bundled
• Mac: bundled on aarch64, system on x64 except 11 and 17 where it's system on both
• Linux (inc.alpine): bundled on jdk8 - system elsewhere

[sxa]

The zlib topic was discussed by the PMC today, and there was general agreement to move to using bundled as a preference, although it was noted that there may have been a technical reason for the 11 and 17 releases on macos to be different from the others, so that is something to be aware of. We would likely switch over after the July set of releases (Although we could switch Linux to JDK21 now since that is not part of the July release). Noting also that we would need to revisit dependencies in the docker and installer images to ensure we are not pulling in anything unnecessarily after this change

[sxa]

Similar to the zlib issue we are moving over to using bundled freetype: #freetype - we have started with JDK21+: https://github.com/adoptium/temurin-build/issues/3504