In the future full of SBOMs, be the VEX that can reduce the volume.
Last week, the US White House released a memorandum on software supply chain security (link in comments). SBOM was a heavily featured word in the same...
SBOM - Software Bill Of Materials
3-4 types of professionals should take notice:
1) Software Developers [Suppliers?]: Of course, this is a no brainer! Developers will be required to define and create SBOMs for every release you will do in the future. Also, Devs will have to adhere to standards expected by the ecosystem. Don't worry, there are tools available. Some are mentioned in the comments.
2) Software Buyer/Procurement team: Inspect the licenses(open vs proprietary), the package, the components and vulnerabilities that unfortunately tag along. Insist on SBOMs to get transparency on all of these items!
3) Software Operators / Security Professionals: You will need to worry about how to consume and interpret SBOMs. SBOMs will basically help you with details on what vulnerabilities are part of your entire software supply chain. You will then need tools / frameworks like
VEX - Vulnerability Exploitability eXchange.
To reduce the work done by software users for looking into non-exploitable vulnerabilities that don’t ultimately manifest in the final software product, Software Developers can issue a VEX that clarifies the vulnerability's status:
- Not affected - No remediation required.
- Affected - Remediation needed.
- Fixed - Version that's got a patch/fix of previously detected vulnerability.
- Under Investigation - Vulnerability status is unknown but to be clarified in the future.
{Important links about SBOMs have been included in the post comments.}
Top comments (3)
What a joke! There is no way to enforce these regulations outside of government agencies.
Plus, most projects nowadays use package managers anyways. The only difference between a dependency list and a SBOM is a few anal policy makers.
The ironic part is most agencies are built on FOSS. So when they start making these requirements, they're shooting themselves in the foot because people who volunteer their code are not going to care.
IMO if the US Government wants change from developers, they're going to have to submit an issue or a pull request like the rest of the world.
Hey wade, thanks for the honest feedback. However, in my opinion,
These will be the enforcement methodologies with regards to SBOMs:
1) ecosystem expectations (your sales and marketing folks will pressure you to create products having these additional artifacts as a competition strategy)
2) government/ industry mandates
3) adoption by FOSS agencies such as the Linux Foundation and CNCF
Whitehouse Announcement - whitehouse.gov/omb/briefing-room/2...
Detailed article on SBOM - sysdig.com/blog/sbom-101-software-...
VEX - ntia.gov/files/ntia/publications/v...
Video on SBOM from NTIA: https://www.youtube.com/watch?v=6yljBKKl8Vo&list=PLO2lqCK7WyTDpVmcHsy6R2HWftFkUp6zG&index=1
On-demand webinar on SBOM and software supply chain security: sysdig.com/resources/webinars/beco...