Software Bills of Behaviors: Why SBOMs aren't enough

The talk opens with the SolarWinds compromise and the 3CX attack, showing how trusted software can be altered after source review and signing. The speaker argues that software bills of materials, which list a product's components, help with compliance but do not reveal what software will actually do once it runs. Because trust is spread across compilers, vendors and open-source dependencies, verification has to be ongoing.

The middle section proposes a software bill of behaviors: a record of network connections, data use, file and host activity, and technique mappings. Behaviors can be gathered by asking vendors, reading open-source code, analyzing binaries, or observing runtime, though developers often lack that visibility. Examples include privacy-label mismatches and a crypto-mining feature that took months to surface. Baselines make unexpected changes between versions stand out, which can cut alert fatigue and inform patching decisions.

The closing part covers scanner noise, such as flagged functions a product never calls, and shows a backdoored Notepad build that launched a calculator without drawing attention. The takeaways are that SBOMs are a baseline rather than a complete answer, that teams should request behavior information from suppliers and build their own baselines, and that security staff should frame these asks around what developers care about.