Add syft namespace for CycloneDX properties

[sambhav]

syft is currently using CycloneDX properties field for storing various custom values. This is a registration request to register a syft cyclonedx namespace.

cc: @luhring, @wagoodman, @spiffcs, @kzantow to review this request before the CycloneDX core team reviews/merges this.

Fixes anchore/syft#821

[stevespringett]

We can certainly approve the syft namespace. However, as a suggestion, a company namespace may provide a bit more flexibility and extensibility for future use cases. We did this for aquasecurity for example.

A few possible examples of what I'm referring to:

anchore:syft:xxx
anchore:grype:xxx
anchore:data:xxx
anchore:cis:benchmark:xxx
anchore:policy:custom:xxx
anchore:component:altcpe
anchore:component:identification:confidence

IMO, the namespace should take into consideration the Anchore commercial products and data along with the incredible open source work the organization leads.

[sambhav]

Gotcha! My reasoning for choosing syft over anchore is noted at anchore/syft#819 (comment). But ultimately it's the syft maintainers' and anchore's call to make and not mine.

[luhring]

I lean toward "syft" for the namespace, for the reason @samj1912 mentions (and more generally, to allow for the flexibility of Syft to exist beyond an Anchore-owned project):

My reasoning for choosing syft over anchore was in case there was ever some movement in the future on ossf/tac#70. The choice of a namespace like syft ensures that the namespace is easily identifiable and closely associated to syft while still being impervious to such changes.

That said, I want to understand all the consequences...

However, as a suggestion, a company namespace may provide a bit more flexibility and extensibility for future use cases.

@stevespringett What kind of flexibility do you have in mind?

[stevespringett]

Decoupling the syft namespace from Anchore, the company, is a really good idea.

My thought for having a more generally scoped namespace are to:

• Support data that Syft isn't responsible for, such as:
  • Vulnerability confidence from Grype. Should it besyft:vulnerability:confidence, grype:vulnerability:confidence, syft:grype:vulnerability:confidence, or anchore:grype:vulnerability:confidence?
  • CIS benchmark compliance from commercial tools in the SBOM.
• Support the ability to distinguish which tools or processes are responsible for, or generated the custom properties.

With that said, I personally like the syft namespace as it's decoupled from the company. However, there are some use cases I think that could be confusing to SBOM consumers if not thought through.

[sambhav]

I want to preface this comment with the same note as above around grype maintainers making the final call but IMO when we get to the point of needing cyclonedx properties in grype (probably after we have basic VEX support in grype), we can register the grype namespace as well following the same logic as above. As of now, syft is completely unaware of grype or vulnerabilities data and entirely focuses on SCA and component inventory in offline mode. Grype is currently dependent on syft but only uses it to get component data and then enrich it with vulnerability information. For the cases listed above, they can potentially fall under the grype namespace (option 2).

[luhring]

I like this direction. The other uses of Syft properties that I'm aware of would fit squarely in the "syft" domain. In the near future, as we continue to enhance our support for CycloneDX, I think a "grype" namespace might make sense to add, but we can discuss that down the road.

(And as @samj1912 mentions, the interchange between Syft and Grype happens in Grype, which already uses Syft logic to decode input data as needed — so I'd think the ingestion of "syft" namespaced-properties into Grype wouldn't cause concern.)

I appreciate the thoughtful discussion here! It's great to see this fluid collaboration. 😀

[stevespringett]

Fantastic. Thanks for the collaboration and support of CycloneDX.