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
Currently, the way that packit determines which SBOM versions to generate is quite rudimentary. There is a hard-coded mapping of versions to their corresponding formats. This implementation notably lacks:
SemVer version parsing: the mapping looks for exact version matches only
support for the latest SBOM schema versions that Syft supports: we pin to specific (and sometimes outdated) schema versions
pinning by default is still advantageous, since changing SBOM schema between builds could be a breaking change for users, but it'd be nice to allow users to "get the latest"
We should investigate whether it's possible to learn the schema versions that a given version of Syft supports before SBOMs are generated. This could allow us to match user-requested versions with versions available directly from Syft. For instance, if a user requests a Syft SBOM version 4.* and the latest version of Syft generates version 4.1.0, we could use the upstream SBOM format rather than one of our own implementations.
The text was updated successfully, but these errors were encountered:
Currently, the way that packit determines which SBOM versions to generate is quite rudimentary. There is a hard-coded mapping of versions to their corresponding formats. This implementation notably lacks:
We should investigate whether it's possible to learn the schema versions that a given version of Syft supports before SBOMs are generated. This could allow us to match user-requested versions with versions available directly from Syft. For instance, if a user requests a Syft SBOM version
4.*
and the latest version of Syft generates version4.1.0
, we could use the upstream SBOM format rather than one of our own implementations.The text was updated successfully, but these errors were encountered: