Ya Got Trouble And SLSA May Help

Nicole Schwartz opens by comparing software to physical products: code is assembled from many suppliers, so the same supply chain risks apply to what developers pull in from platforms, dependencies and vendors. She frames the discussion around government expectations for secure software, which push suppliers toward documented practices, and argues that developers and security staff should learn those requirements early rather than meeting them as a late hurdle.

The middle of the talk walks through the requirement areas tied to SLSA. These cover how a build is produced, whether its output can be checked against what was intended, and how provenance records let someone trace when and how an artifact was made. She also covers having a working vulnerability response program and checking open source components as part of the same picture.

To close, she warns that teams motivated to satisfy a checklist can hollow out the intent, and that controls are hard to enforce when individuals argue their way around them. The practical takeaway is to spread ownership across development, security and operations, and to start with the fundamentals of build integrity and known-vulnerability handling rather than paperwork alone.