Challenge 1: Updating Vulnerable Dependencies

As software dependencies evolve, users of these dependencies may need to update. Updating dependencies is the most common strategy to react to known vulnerabilities in dependencies. Delaying updates can cause problems when updates are eventually needed, for example to reacting to detected vulnerabilities. There are many unknowns on how and when to update dependencies and how much to automate. For example, historically, developers and security experts have disagreed on whether pinned or floating dependency versions are a good idea. Developers like fixed dependencies: they prevent changes from breaking their project. In contrast, security experts have long touted the mantra of automatic updates, even for software dependencies. They argue that the widespread adoption of more agile “move fast and break things” approach to software development can tolerate changes in dependencies, and it is better to have the latest version of a dependency in case there was an unannounced security fix. Little data exists to provide evidence and recommendations beyond anecdotal evidence.

Challenge 2: Choosing Trusted Supply Chain Dependencies

Challenge 2 Icon

To what extent should one trust a statement that a program is free of Trojan horses? Perhaps it is more important to trust the people who wrote the software.

-Ken Thompson

The software supply chain requires trust, for example, when bringing in dependencies. By definition, every dependency is outside the trust boundary. The now famous XKCD comic 2347 illustrates how much of modern software relies on software packages developed and maintained by others and largely invisible to most software developers. In practice, few people if any ever critically audit all their direct and indirect dependencies and all their updates; most simply trust the developers and trust that the rest of the community would notice and report problems if any exist. A world without trust where everybody had to independently audit every dependency would be costly and inefficient for the entire community. However, this leaves us with various questions about trust: Can you trust the maintainers of a library over time? What about the integrity of the library’s build environment or the compiler? Will an organization sell or turn over their library to someone malicious? What if a library is deleted and someone takes the name? Can the accuracy of the SBOM be trusted? How can trust be observed or measured? When is trust appropriate and when is it misplaced?

Challenge 3: Leveraging SBOM for Security

Challenge 3 Icon The US Whitehouse Executive Order 14028 brought the Software Build of Materials (SBOM) into the limelight in a big way, requiring it for all software to be sold to the US government. Over the last ten years, a number of industrial efforts, such as SPDX, CycloneDX, and SWID, have sought to standardize machine readable formats of the SBoM for modern environments. Conceptually, an SBoM is a list of all the code and build dependencies (and ideally version information) that went into creating a software product, thus providing transparency about the product and its dependencies. While there are well-founded concerns that current SBoM are largely a compliance exercise, they also can provide value to various stakeholders if produced accurately and consumed deliberately. However, efforts at establishing standards and requirements for SBoM have the potential to lay the ground work for innovative security enhancements that leverage the SBoM. We need to create and automate metrics that are verifiable, meaningful, non-game-able, and attestation-able with the ability to demonstrate adherence to security policies and we need to explore how to consume SBoMs in a way that creates actual value and contributes to security.

Challenge 4: Securing the Build Process

Challenge 4 Icon Build specifications and environments have often been overlooked by security analysis efforts. The recent wide-spread adoption of popular Continuous Integration and Continuous Deployment (CI/CD) tools, such as Jenkins, Circle CI, Tekton, and GitHub Actions, provides a foundation for establishing documented and attestable build environments. However, they also open the attack surface for injecting malicious code during the build process. For example, a large community has developed around providing reusable GitHub Actions to perform common CI/CD tasks, yet these GitHub Actions do not always have strong access control and integrity protection. The Supply Chain Levels for Software Artifacts, or SLSA (pronounced “salsa”), framework provides a check-list of standards for reasoning about the build process. SLSA is based on Google’s internal processes and defines four levels, beginning with simply having a scripted build and recording provenance information and ending with using an ephemeral, isolated, parameterless, and hermetic build environment. Bonus points are given if the build is reproducible, i.e., two builds produce bit-for-bit identical output. SLSA is a great starting place to think about the problem, but research is needed to identify how to secure builds effectively and with reasonable costs.

Challenge 5: Getting Industry-Wide Participation

Challenge 5 Icon The big tech giants are acutely aware of the software supply chain risk and have been for some time, sometimes after falling victim to supply chain attacks. Some of them have created short-term solutions such as repositories of “verified” dependencies that their developers may select from. Not only are these efforts manual and laborious, they only help that company and not the larger community, and they may be limiting to developers in that company. Collective trustworthy efforts that contribute to the common good are needed to secure the software supply chain in the long term. Fortunately, the major players in the industry are already coming together through the form of a number of projects, including those under the umbrella of the Linux Foundation and the OpenSSF. However, it is not enough for these collaborative efforts to simply exist. They need to be adopted and used by the large majority of the software industry. This transition will not be easy, and it will take time. The Building Security In Maturity Model (BSIMM) has become the de facto standard for assessing a company’s software security practices and providing an industry-wide picture of practice adoption. A “BSIMM for Supply Chain” would go a long way towards helping software companies understand software development and build practices they should adopt to improve supply chain security.