Software Transparency

Foreword

Many of us will remember December 2021 as a time spent hunched over small travel laptops in relatives' guest rooms, dealing with the Log4j crisis. That vulnerability in an open source Java-logging framework developed by The Apache Software Foundation was scored as severe by both official metrics and software experts. It was not the hardest vulnerability to address, either through patches or other inline mitigations. Yet, the real challenge most organizations faced was location: Where is this darn thing? Buried deep in countless modern applications' supply chains, both producers and users of software simply didn't have a usable roadmap of where to focus.

The hard part of security should be in identifying vulnerabilities and discovering attackers sneaking into our supply chains. Instead, we've discovered that understanding what's in the software we make has required a nontrivial amount of work.

The idea of tracking what goes into software isn't new. Academics have been talking about it since the 1990s. Early idea discussions were happening in disparate corners of the software world in the 2000s. Failure to account for the open source licenses got a number of large companies into serious legal trouble. Collecting and leveraging supplier data formed an integral part of the revolution in heavy industry quality that dates back to the late 1940s, with the Deming and the “Toyota revolution” that inspired the DevSecOps and modern software revolution decades later.

Indeed, it's ...