Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

SWID is a recognized SBOM format by NTIA #50

Open
riteshnoronha opened this issue Feb 20, 2023 · 3 comments
Open

SWID is a recognized SBOM format by NTIA #50

riteshnoronha opened this issue Feb 20, 2023 · 3 comments

Comments

@riteshnoronha
Copy link
Contributor

Add support to score SBOM generated in SWID format

SWID tags can be used as an SBOM, since they provide identifying information for a software
component, a listing of files and cryptographic hashes for the constituent artifacts that make up
a software component, and provenance information about the SBOM (tag) creator and software
component creator. Tags can explicitly link to other tags, enabling a representation of a
dependency tree

@viveksahu26
Copy link
Collaborator

viveksahu26 commented Jul 18, 2024

Do we need to proceed with this ? Although SWID is available for SBOMs but resources related to it are rarely available, For example, no tool available to generate SWID format SBOMs, and also didn't find examples of SWID SBOMs.

SWID is seen today as less of an SBOM format and more of a software descriptor, and according to NIST, is seen as one possible successor to the beleaguered CPE naming standard. The reason why CPE has become so problematic is two-fold. One, these CPE values are manually assigned, and as such suffer from inconsistency. Secondly, CPE is focused on product-level naming, but very few software components are featured in the National Vulnerability Database, so relying on a CPE to describe a vulnerability in a software component will not be very reliable.

While we have not seen anyone use SWID as an SBOM format, it does have a role to play. Much of the industry’s current focus is on managing the risk of open-source dependencies, and approaches such as PURL are well-supported by package managers to do this work. But SWID solves the challenge around software naming when the software package is not publicly known or distributed, such as in the case of proprietary software.

The reason why SWID is not used for SBOM is that it is not really an SBOM format. It describes key characteristics of software such as the software name, version, suppliers and other metadata. It also provides some useful context for supply chain concepts such as pedigree in the form of patch metadata. But the data format itself is not conducive to the concept of nested layers of software components and their dependency relationships, otherwise known as transitive dependencies.

And few more resources on SWID.

@riteshnoronha WDT ??

@cburley96
Copy link

Is this a feature that is planned to be completed? Just curious as this is a tool I find useful and this feature would be useful as well.

@viveksahu26
Copy link
Collaborator

Do you generate SBOM with SWID format and which tool do you use to generate that.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants