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
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
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
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
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.