6 ms·

The Minimum Elements for a Software Bill of Materials (SBOM)

23 points by infodocket 5y ago

publicola1990 5y ago
It seems here SBOMs are being considered from a security perspective, but in the hardware world BOMs are ubiquitous. Hardware BOMs are made and maintained so that the buyer of the hardware knows what exactly they are getting.
- icegreentea2 5y ago
  Ya, I think its mostly an incentive thing. Software just isn't use to doing BOMs (though certainly lots of B2B sales have something like BOMs changing hands). The incentives just aren't there for this to happen without some sort of push.
mikewarot 5y ago
Something worth watching: If you had a comprehensive database of most of the publicly available software, and their SBOMs, you could recursively scan for all the packages vulnerable to newly discovered bug X, which is something that was previously obscure. Something worth considering: A government agency could fund two separate programs be developed to do the same thing with the proviso that they share NO components anywhere in their tree. It might help find bugs, and improve redundancy. You could also specify that they each must pass each other's unit testing. Something worth considering: If you had a large database of most publicly available SBOMs, you could find the previously unknown critical providers and target or fund them, depending on your goals.
bfrog 5y ago
Questions that aren’t being answered by the NTIA pushing this. Why would a vendor do this and become liable for all inclusive software? The build chain isn’t required to be part of the BOM so any trojaned tool in the build environment may pass along the Trojan modifying the outcome drastically, the BOM is useless there. People were selling snake oil saying this would solve solar winds. No.
- rswail 5y ago
  They're doing it because the Executive Order requires it if you want to sell software to the US Federal Government. By default, what the USG demands becomes a more general thing, as other governments and levels of government adopt the same standards. Then vendors will produce it and it will become a condition of commerical contracts. The vendor is already liable (or should be) for knowing what's in the product they've supplied. This is just a way of documenting it in a standard way.
rswail 5y ago
Good foundation for your own CMDB (if you do ITIL and Change Management) internally. This will make software companies have to publish their detailed internals in a way that is readable and auditable, unlike looking in the "Legal" fine print for their 3-point flyspeck font list of what opensource libraries they've used.

23 points by infodocket 5y ago

publicola1990 5y ago

It seems here SBOMs are being considered from a security perspective, but in the hardware world BOMs are ubiquitous. Hardware BOMs are made and maintained so that the buyer of the hardware knows what exactly they are getting.

icegreentea2 5y ago
Ya, I think its mostly an incentive thing. Software just isn't use to doing BOMs (though certainly lots of B2B sales have something like BOMs changing hands). The incentives just aren't there for this to happen without some sort of push.

mikewarot 5y ago

Something worth watching: If you had a comprehensive database of most of the publicly available software, and their SBOMs, you could recursively scan for all the packages vulnerable to newly discovered bug X, which is something that was previously obscure. Something worth considering: A government agency could fund two separate programs be developed to do the same thing with the proviso that they share NO components anywhere in their tree. It might help find bugs, and improve redundancy. You could also specify that they each must pass each other's unit testing. Something worth considering: If you had a large database of most publicly available SBOMs, you could find the previously unknown critical providers and target or fund them, depending on your goals.

bfrog 5y ago

Questions that aren’t being answered by the NTIA pushing this. Why would a vendor do this and become liable for all inclusive software? The build chain isn’t required to be part of the BOM so any trojaned tool in the build environment may pass along the Trojan modifying the outcome drastically, the BOM is useless there. People were selling snake oil saying this would solve solar winds. No.

rswail 5y ago
They're doing it because the Executive Order requires it if you want to sell software to the US Federal Government. By default, what the USG demands becomes a more general thing, as other governments and levels of government adopt the same standards. Then vendors will produce it and it will become a condition of commerical contracts. The vendor is already liable (or should be) for knowing what's in the product they've supplied. This is just a way of documenting it in a standard way.

rswail 5y ago

Good foundation for your own CMDB (if you do ITIL and Change Management) internally. This will make software companies have to publish their detailed internals in a way that is readable and auditable, unlike looking in the "Legal" fine print for their 3-point flyspeck font list of what opensource libraries they've used.