Difference between revisions of "SBOM"

From MgmtWiki
Jump to: navigation, search
(Full Title)
(Context)
Line 4: Line 4:
 
==Context==
 
==Context==
  
. Software developers and vendors often create products by assembling existing open source and commercial software components. The SBOM enumerates these components in a product. It is analogous to a list of ingredients on food packaging. An SBOM is useful to those who develop or manufacture software, those who select or purchase software, and those who operate software. Developers often use available open source and third-party software components to create a product; an SBOM allows the builder to make sure those components are up to date and to respond quickly to new vulnerabilities. Buyers can use an SBOM to perform vulnerability or license analysis, both of which can be used to evaluate risk in a product. Those who operate software can use SBOMs to quickly and easily determine whether they are at potential risk of a newly discovered vulnerability. A widely used, machine-readable SBOM format allows for greater benefits through automation and tool integration. The SBOMs gain greater value when collectively stored in a repository that can be easily queried by other applications and systems. Understanding the supply chain of software, obtaining an SBOM, and using it to analyze known vulnerabilities are crucial in managing risk.
+
Software developers and vendors often create products by assembling existing open source and commercial software components. The SBOM enumerates these components in a product. It is analogous to a list of ingredients on food packaging. An SBOM is useful to those who develop or manufacture software, those who select or purchase software, and those who operate software. Developers often use available open source and third-party software components to create a product; an SBOM allows the builder to make sure those components are up to date and to respond quickly to new vulnerabilities. Buyers can use an SBOM to perform vulnerability or license analysis, both of which can be used to evaluate risk in a product. Those who operate software can use SBOMs to quickly and easily determine whether they are at potential risk of a newly discovered vulnerability. A widely used, machine-readable SBOM format allows for greater benefits through automation and tool integration. The SBOMs gain greater value when collectively stored in a repository that can be easily queried by other applications and systems. Understanding the supply chain of software, obtaining an SBOM, and using it to analyze known vulnerabilities are crucial in managing risk.
  
 
Commentary
 
Commentary
 
It is not clear who will be responsible for defining a SBOM. Here is one current problem. There is a open source product did:orb that includes a make file that depends on GCC (the Gnu Compiler). Now the problem is that there is no way to build the code without these tools. I am unclear how it could be possible to know if the tools provided any contribution the the finished products if it is required to build the product. So, is the GCC part of the did:orb SBOM? The following wiki page contains a sample SBOM, Did:orb#Software_Bill_of_Materials.
 
It is not clear who will be responsible for defining a SBOM. Here is one current problem. There is a open source product did:orb that includes a make file that depends on GCC (the Gnu Compiler). Now the problem is that there is no way to build the code without these tools. I am unclear how it could be possible to know if the tools provided any contribution the the finished products if it is required to build the product. So, is the GCC part of the did:orb SBOM? The following wiki page contains a sample SBOM, Did:orb#Software_Bill_of_Materials.
 +
 
==References==
 
==References==
  
 
[[Category: Trust]]
 
[[Category: Trust]]

Revision as of 10:22, 11 February 2022

Full Title

“Software Bill of Materials” or SBOM means a formal record containing the details and supply chain relationships of various components used in building software

Context

Software developers and vendors often create products by assembling existing open source and commercial software components. The SBOM enumerates these components in a product. It is analogous to a list of ingredients on food packaging. An SBOM is useful to those who develop or manufacture software, those who select or purchase software, and those who operate software. Developers often use available open source and third-party software components to create a product; an SBOM allows the builder to make sure those components are up to date and to respond quickly to new vulnerabilities. Buyers can use an SBOM to perform vulnerability or license analysis, both of which can be used to evaluate risk in a product. Those who operate software can use SBOMs to quickly and easily determine whether they are at potential risk of a newly discovered vulnerability. A widely used, machine-readable SBOM format allows for greater benefits through automation and tool integration. The SBOMs gain greater value when collectively stored in a repository that can be easily queried by other applications and systems. Understanding the supply chain of software, obtaining an SBOM, and using it to analyze known vulnerabilities are crucial in managing risk.

Commentary It is not clear who will be responsible for defining a SBOM. Here is one current problem. There is a open source product did:orb that includes a make file that depends on GCC (the Gnu Compiler). Now the problem is that there is no way to build the code without these tools. I am unclear how it could be possible to know if the tools provided any contribution the the finished products if it is required to build the product. So, is the GCC part of the did:orb SBOM? The following wiki page contains a sample SBOM, Did:orb#Software_Bill_of_Materials.

References