No SBOM Will Not Solve All Your Software Supply Chain Problems

The talk questions whether software bills of materials (SBOMs) can stop supply chain attacks. The speaker notes that SBOMs have become a regulatory requirement, and that many vendors supply them as a cheap checkbox. He argues that an SBOM mostly lists components and version numbers, which says little about whether something will behave maliciously. Version numbers are weak evidence: he contrasts a legitimate PuTTY release with a North Korean backdoored build that carried the same version, and he points out that a CPE identifier for the project changed over time.

He then goes through other defenses. Code signing does not help when a build system is compromised, because malware gets signed anyway. Reproducible builds still reproduce whatever malicious code entered the source. Building the same software on multiple systems is harder for attackers, but it still leaves the question of whether the result is trustworthy. He also accepts that SBOMs are useful for vulnerability management, while criticizing vendors who present known CVEs as if they were supply chain compromises.

He closes by observing that customers and end users rarely ask for these controls, and that questionnaires reduce security to checkboxes. He sees some progress in heavily regulated sectors such as finance and healthcare. The takeaway for practitioners is that an SBOM is a useful inventory but not an answer to whether a dependency will do something harmful. Tools should aim at that question.