Extra information needed for SBOM

[agallero]

We are already providing basic information about dependencies, etc with tms snapshot. We've been asked about some other information that could be added there to make the SBOM generators generate more complete files. This information should be in tmsbuild.yaml, and it is all optional. But of course if you don't fill it it just won't show in the sbom

The ones I can think right now:

• license
• license_url? -> not sure how this will work with something like MIT (probably leave it empty). For something like tmssoftware. it would be "license: proprietary" and license_url: someurl where the license is.
• contact_info? We already have url, but we could also have some email here. Maybe contact_email is more correct as contact could be also some phone number, what's app, I don't know.
• release date? Not sure if this is needed, but we could automate a way to get it.

I am no expert in SBOM, so I don't really know what would be desirable, what would not and whatelse. This is just my starting point to see what should be added. Any other suggestions (or clarifications in the suggested fields is welcome 🙂). The only thing is that we want to add information here that is not possible to get in other way for the SBOM tool. For example, not include a hash here, since they can calculate the hash themselves. They can't figure out what the support email is, but they can figure out the hash.

[agallero]

Just for the record, as mentioned in #13 (comment) we should also be careful in which info is easy to go stale and become invalid. License is probably fine as it doesn't really change much, but other stuff might require a lot of maintainance and so is not desired

[agallero]

other thing that might be interesting for a sbom tool. which other native deps it has, with version? For example, smartsetup itself links zstd 1.5.7 and also to zlib (version that comes with delphi 13). FlexCel comes with a skia backend.

This information will be a pain to enter (if people even enter it correctly), but it might be the simple most important thing here. You can easily see the delphi dependencies, that's not hard. Knowing that your app depends in zstd is more complex, the scanner would have to search for {$LINK} directives, and also check for bpls/dlls

[Maenken]

For libraries that “only” need to be available at runtime, you can omit the @1.2.3 from the PURL; this is optional
My scanner detects the DLLs being used if they are statically linked; for dynamically linked ones, a feature will be added in the coming weeks to add them to the project.
If the DLL is provided by a component, then it should be listed in the dependency. This is particularly desirable for dynamic DLLs.
But as mentioned, the version can be omitted for such a “weak” dependency.
This should simplify the maintenance of the information, since the SBOM merely specifies that a certain library must be present on the system; the situation is naturally different for components; but even there, you can simply list the dependency without a version; the tool that subsequently performs the final compilation then adds the compiled dependency of the component used. This ensures that the version is retained.