[FEATURE]: Component Type unknown

[VictorHuu]

Describe the feature

This PR is about the issue.

We should add a component type unknown since with the development of tech ,there are always new types that will emerge, and the SBOM generator like Syft can't handle all of the types currently given that exhaustive implementation for all is almost impossible. The type unknown is used as a fallback for various unrecognized values

Possible solutions

The solution is very simple ,so no need to elaborate on.

Alternatives

None

Additional context

Relative issue about the downstream scenarios:

1. Syft convert from cdx.json -> syft.json -> cdx.json fails anchore/syft#3574

[jkowalleck]

Why? Why "unknown" ? How can there be a component of unknown type?
Whe you know a component exists, you MUST knoe its type, right?

Please provide a real world example.
Thabks in advance.

[VictorHuu]

The type is application in the latter bom, not because it's indeed an application, just because ComponentTypeApplication is the default enum option when the type of the former syft bom is unknown,empty or some other strings.

[jkowalleck]

let me summarize your example:

1. you have this CycloneDX bom.json - having a certain component of type "application"
2. you convert this file to syft data-format bom-syft.json - and this loses the information that a certain component had a known type
3. you convert this file back to CycloneDX and the information that was lost is now still missing and syft's converter makes things up ...

have you considered asking syft to enhance their data format to enable it carrying the data?

[VictorHuu]

Though the Syft maybe inconsiderate, but when the primaryPackagePurpose is OTHER, it has already lost the information. Of course Syft is incapable to handle an SPDX SBOM whose primaryPackagePurpose is OTHER then.

Back to the 1st question ,I've contacted the syft team, and I've been contributing to this. But I found that enabling it carrying the data involves a lot of updates to the Syft code. Syft itself has an SBOM standard, adding support for so many types needs a lot of discussion and negotiation only as a completeness measure.

[jkowalleck]

Syft itself has an SBOM standard, adding support for so many types needs a lot of discussion and negotiation only as a completeness measure.

have you tried it? I mean, they (syft) are the ones lacking the feature; how would they know that it is needed if nobody asked for this feature?

[VictorHuu]

OK, I've attempted to support the feature. So this discussion can be closed soon

[VictorHuu]

@jkowalleck Well, a SBOM related software should know the type of a component eventually, but maybe not present.Now, I think its the duty of implementation not specification. Sorry for my thoughtless PR.

[nscuro]

@jkowalleck I imagine this is a common issue for folks converting between formats. Presumably the alternative to unknown would be to pick one of the available types, but then type could no longer be treated as an assertion. evidence.identity doesn't support type, so confidence cannot be communicated.

Practically speaking, is there any "safe" way for @VictorHuu to achieve their goal without risking populating the BOM with plain wrong data? Since type is required, leaving it empty is not an option.

[jkowalleck]

We should add a component type unknown

sorry, i still don't see a description of a problem.
Instead, i see a proposal for a "solution", without any background. I will convert this ticket to a discussion, so that a proper requirements engineering might happen.