You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This idea came from @samj1912 on a recent community meeting as well as a previous prototype.
Today we've started adding the ability to encode and decode from any SBOM format. However, not all fields are translatable from every format to every other format. The syft-json format contains all possible information that we can express and converting to SPDX or CycloneDX is usually lossy. This means when we start to implement the syft convert command in the future, there will be paths that would lead to information loss which are not apparent to the user.
We could keep extra information in all SBOM formats encoded out-of-band of the spec in select fields. For instance, in cyclone DX we could preserve most unsupported package fields within the properties of the package object. For SPDX we could encode the original unsupported fields into a comments field with bas64 encoding.
Something similar to this was done in the past as a prototype with SPDX json: #578 We ended up not going that directing and keep as in-spec as possible.
The text was updated successfully, but these errors were encountered:
This idea came from @samj1912 on a recent community meeting as well as a previous prototype.
Today we've started adding the ability to encode and decode from any SBOM format. However, not all fields are translatable from every format to every other format. The syft-json format contains all possible information that we can express and converting to SPDX or CycloneDX is usually lossy. This means when we start to implement the
syft convert
command in the future, there will be paths that would lead to information loss which are not apparent to the user.We could keep extra information in all SBOM formats encoded out-of-band of the spec in select fields. For instance, in cyclone DX we could preserve most unsupported package fields within the
properties
of the package object. For SPDX we could encode the original unsupported fields into a comments field with bas64 encoding.Something similar to this was done in the past as a prototype with SPDX json: #578 We ended up not going that directing and keep as in-spec as possible.
The text was updated successfully, but these errors were encountered: