Add Red Hat taxonomy

[mprpic]

Follow up from #52.

[mprpic]

@vibe13 I reformatted the table into markdown but wasn't able to push into your forked branch so I created this branch. You can push to it directly too if you want to make additional edits.

General question: I would have expected all of the sbomer properties to still be namespaced by redhat since that is how we use them. If we want to keep them generic, then I think we'd have to reserve a separate sbomer namespace and have a separate taxonomy for those properties, no?

[vibe13]

@mprpic thanks for re-creating this PR.
Wrt sbomer properties: yes I opened the original PR with the status quo of the properties added by SBOMer, but there was a pending decision to be done, whether prefixing all/some of the properties to redhat:sbomer: or to rename all/some of them to redhat: without the sbomer: prefix. Once we have an agreement I can update SBOMer and update this PR as well!
Thanks!

[vibe13]

@mprpic Ok I have added the redhat namespace to all the labels now.

[goldmann]

Let me put a few points for discussion:

1. IMO I would probably like see less properties, but these should be meaningful and useful and we should have no doubts about them. I can create a proposal of what I think it's worth, then we can argue :)
2. I would group properties by content type. So, for container images have a separate section (table). This would make it easier to get an overview and skip anything that you do not care about.
3. I would drop sbomer from the namespace. I don't think the tooling that generates this is interesting and even more, it will just cause problems. Tooling information should be represented differently. If we have use cases, where we think a property should be represented, we can use sbomer as the prefix (without registering, for now) to have a way to add it and see whether this should be "promoted" to redhat namespace. See 1, it's related.
4. I would drop most of the labels.*. If the underlying build system changes, we will not be able to provide it.

Let's talk!

[vibe13]

@goldmann All good points!

IMO I would probably like see less properties, but these should be meaningful and useful and we should have no doubts about them. I can create a proposal of what I think it's worth, then we can argue :)

Ok, let's see what makes sense to keep!

I would group properties by content type. So, for container images have a separate section (table). This would make it easier to get an overview and skip anything that you do not care about.

100%

I would drop sbomer from the namespace. I don't think the tooling that generates this is interesting and even more, it will just cause problems. Tooling information should be represented differently. If we have use cases, where we think a property should be represented, we can use sbomer as the prefix (without registering, for now) to have a way to add it and see whether this should be "promoted" to redhat namespace. See 1, it's related.

Ok, going a step further, so should we even rename them from syft: to sbomer: then? Do we want to mask the fact that those were gathered by the underlying open source tooling?

I would drop most of the labels.*. If the underlying build system changes, we will not be able to provide it.

Mmmm why? They don't cause any harm and we don't know what we would need in future..... I believe that even if we list a property in the taxonomy (and we agree we want less of them listed) it does not imply that it must be always provided, so it's not a commitment for us to always provide them.

[goldmann]

Mmmm why? They don't cause any harm and we don't know what we would need in future..... I believe that even if we list a property in the taxonomy (and we agree we want less of them listed) it does not imply that it must be always provided, so it's not a commitment for us to always provide them.

I think I failed at giving the context. Let me try fix it now.

By drop I actually meant two things:

1. Refrain from having such a detailed taxonomy -- simply do not add all the labels into our taxonomy. Labels are controlled by image creators and build systems. We do not control anything. There are generic labels that make sense to add, but I would not do it for most of them.
2. Remove labels from manifests with lower impact/priority. One could argue how to understand the impact of a label and based on what we could make this decision. Yes, this is not very well defined.

I'm not sure if the taxonomy does not require us to provide them for a given deliverable type. This is exactly how I read the taxonomy, which for me is a guideline that for type X we should provide property Y which is described as Z. If this is not the case, we probably need to state it very clearly.

Ok, going a step further, so should we even rename them from syft: to sbomer: then? Do we want to mask the fact that those were gathered by the underlying open source tooling?

This is a very good question! When I was originally doing this I was thinking that this is good idea, because the "generator" is SBOMer, no matter what underlying tool we use. I don't think I wanted to hide anything.

I may change my mind and we probably should create some rules about we should approach it. Here is an example:

1. Do not rename properties created by underlying tools.
2. Remove properties that do not make sense or are too verbose. Do this case by case (depends on the underlying generator tool and what it provides). This means that an "adjuster" can be required, depending on the generator.
3. If we add any properties ourselves, use the sbomer namespace for majority of these and the redhat namespace for the important ones that are exposed within RH taxonomy. Please note that what I just wrote above is when the Red Hat enhancer/processor is involved. For cases when it isn't applied, we will NOT produce any redhat properties.

[vibe13]

@goldmann Thanks for the further clarification!

Refrain from having such a detailed taxonomy

Ok I agree. The majority of them (all except the first 3) in the taxonomy are inherited from underlyong tools, so we can avoid to list them. We probably need to specify that not all the properties are mandatory (probably the redhat:advisory_id is the only one, to be verified with Konflux also).

Ok, let's identify then what we want to remove form the labels and what we want to provide with redhat: and sbomer:prefix then :-)