The Case For Inventoring Corresponding Source in SBOMs
- Track: Software Bill of Materials devroom
- Room: K.4.401
- Day: Sunday
- Start: 16:30
- End: 17:00
- Video only: k4401
- Chat: Join the conversation!
SBOMs focus basically exclusively on binary distributions. For years, copyleft activists like me have argued vehemently that they are non-functional in addressing the primary license compliance and software security problem that plagues FOSS distributions: an inability to clearly identify, and assure that all in the supply chain receive, the complete, corresponding source for the binaries in question.
Due to the heavy influence and control on SBOM dialogue asserted by proprietary software companies and their business model proponents, proposals to require source code disclosures as a necessary part of the supply chain have typically been rejected. In short, SBOM focus has been to ease the ingestion of FOSS into proprietary supply chains, rather than assuring that downstream users are afforded the same rights to examination, modification, and reinstallation of FOSS that their upstreams enjoyed. Most will argue, perhaps correctly, that the ship of universal software freedom has sailed, the industry doesn't want to be on it, so why continue to debate that question in the context of SBOMs and (the mostly proprietary) software supply chains in our world today.
This talk, then, proposes a simple compromise. Given the non-viability of convincing proprietary software companies that control the supply chains to actually give software rights and freedom to their users and join the Open Source world, what (this talk considers) is a requirement for SBOMs that might improve the situation for downstream users with regard to complete, corresponding source code provisioning, but would not require companies to participate in actual open source releases?
I will propose in this talk a thought experiment of how we might add key information about the supply chain of the source code that produced the binaries into SBOMs without requiring actual source-code disclosure. While such an addition would be woefully inadequate to assist in compliance with copyleft licenses, it would (a) marginally improve the forensic data available to those trapped at the end of the supply chain desperate to, for example, determine whether they are vulnerable to the latest security bug and (b) provide at least a basic breadcrumbs for those who are testing copyleft compliance of products at the end of the supply chain.
Speakers
Bradley M. Kuhn |