So how do you build your software?

It was the year 2021. My colleague had built language frontends for parsing large python and dotnet projects into an Intermediate Representation (IR) for security analysis. The frontends required the projects to be built prior to invocation and performed well during our testing. With increasing confidence, we took the project to the real-world to a group of design partners to try it out. We then faced reality:

"Many in-house AppSec engineers and even DevOps didn't know how to build their projects"

Is it pip install or python -m poetry install? What version of python, pip, poetry, pip-tools are needed to build this python project?

It was not a great experience for dotnet either. Does this project require .NET framework 6/7 or the .NET core 2.1/3.1? What version of Windows can correctly support these combinations? Is NuGet restore or dotnet restore. How do you correctly authenticate with that private NuGet registry to build these private dependencies if AppSec are not allowed to access then?

After battling for over two years, we decided to admit defeat and build source-based parsers; the ones that do not require any build as required. This is despite knowing that analyzing anything pre-build can increase the false positives.

I am confident that we are not alone in dealing with issues while building software. Build instructions for many software, both modern and legacy, are so complex only a few project maintainers and lead developers know the exact workflows and steps. These steps might be buried in a bunch of make files, ad hoc python scripts, bazel files, and some docker files that must be executed in a specific sequence with some environment variables and more preconditions. When build instructions are non-intuitive, it offers an opportunity for anyone to perform malicious things like injecting random binary payloads, bundling non-approved libraries, or weakening security configuration.

So how do you document the exact formulas, workflows, and steps needed to build, test, deploy, and release software in a consistent format that allows automation and reviews.

Meet formulation

"Formulation" is an underestimated part of the CycloneDX specification, which does not exist in other SBOM standards. With formulation (https://cyclonedx.org/docs/1.5/json/#formulation), the exact sequence of build and release steps can be specified to remove any ambiquity and promote reproducibility for software. Organizations that begin to use formulation even for internal use can find incorrect build steps and non-compliant CI practices within the first few days. It would also help troubleshooting build performance and failures by providing a consistent language to communicate and share knowledge within the organization.

Open-source projects that clearly document build and release procedures can enhance their contributors' base by reducing the friction associated with the initial setup and running initial tests. It could be implemented by the OS distros and container teams to improve testability and compliance.

Towards automating formulation

Some SBOM tools, such as CycloneDX Generator project, can attempt to create a basic formulation. We would like to see more tools and techniques to translate Jenkins pipelines, GitHub/GitLab workflow configuration files, and even make and docker files to an equivalent CycloneDX formulation and vice versa.

Do not hesitate to connect with us via slack (https://cyclonedx.org/slack/invite) should you have any questions or comments about incorporating formulation in your SBOM tools and processes.