Build specifications and environments have been largely overlooked by security analysis efforts. The recent wide-spread adoption of popular Continuous Integration Continuous Deployment (CI/CD) tools, such as Jenkins, Travis CI, Tekton, and GitHub Actions, provides a useful foundation to 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. 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 getting into all of the nooks and crannies is going to take a lot more time and effort.