Hi all,

One of the suggestions in today’s call for the OpenChain Telco SIG, where we’re discussing proposals for an SBOM standard for the Telecommunications industry, was:

> SBOMs conforming to the Telco SBOM Specification need to contain the information when the SBOM was created in the “Created” SPDX field and at what phase of the software build it was created (“pre-build”, “build-time” or “post-build”) in the CreatorComment SPDX field.

(See https://github.com/OpenChain-Project/Telco-WG/pull/15)

I raised a concern about ambiguity here, in that your application may be built from libraries that are built at an earlier stage, so the SBOM information may be created after some components are built, but before others. A recipient of the SBOM might also interpret each of these three phrases differently from the creator of the SBOM. I recall hearing that there have been conversations about many different SBOMs according to phase (source SBOM, build SBOM, deploy SBOM, cloud SBOM, etc.), so I wondered whether there was advice that the Telco SIG could lean upon, rather than trying to formulate a solution when it’s already a solved problem.

Apologies if this isn’t the right group.

steve

Steve,

SBOM’s are created to serve a purpose, for example some SBOM’s are used for license management, some are used for dependency tracking and the one I’m most familiar with is an SBOM used by a software consumer in a software risk assessment.

In the risk assessment case it’s imperative that the SBOM describe the contents of a software package used for installation and execution in a consumers digital ecosystem. Data in this SBOM, i.e. component names and versions, is more compatible with vulnerability databases when searching for CVE’s filed against component software, i.e. Log4j is a good example.

I can’t speak to SBOM’s used for other purposes.

Hi Steve,

I’m going to include the SPDX tech group on the email thread – sorry to many of you for the duplication.

Steve – If you’re a member of that email we can continue the thread there.

There is a Build Profile working group which is tackling very similar problems for the SPDX 3.0 spec led by Brandon and Nisha (cc’d) – you may want to connect with that group.

For SPDX 2.3, I have a couple of thoughts and suggestions.  I think the Creation Information created date will provide the information on when the SBOM was created.  We don’t have any fields at the SPDX Document level to store and retrieve the build phase information, but we have added 3 new fields at the package level which may be useful:

• Built Date
• Release Date
• Valid Until Date

For a typical SBOM, the SPDX document will have a Document Describes which points to the package the SBOM is describing.  Although it isn’t direct, you could use the Built Date and Release Date along with the Creation information to determine where in the lifecycle the SBOM was created.  Since these are optional fields, the Telco SIG would need to specify that they be included for the package in the Document Describes field.

Using the comment field for information not in the SPDX spec is an acceptable practice – especially if the information is intended to be human readable.  You can also use an Annotation on the SPDX document for the same purpose.  The advantage of the Annotation is you can have more than one with each Annotation having a specific purpose.  For example, you could have an Annotation “Build-Phase: pre-build” and an separate annotation for unrelated information.

Best regards,

Gary

Having also been in that call I would also like this clarification. The idea behind having this information available is for the recipient to make her or his own judgement on how accurate they expect such to be.

If this has been solved in the SPDX community that would be great. 😊 Steve’s comments on different “stages” was not something I had considered, but it does potentially complicate things.

BR J