In today’s world, the primary mode of building software is, first and foremost, starting with software someone else has written. This mode includes open source, but this situation is not limited to open source. Many companies are selling their closed-source technology or opening their source code to the world while offering a support package. This software includes but is not limited to source code, compiled binaries, and other software artifacts. This software is precious because the software solves everyday problems. The software allows engineers, companies, and organizations to focus on creating new value and assets.
No software is perfect. All software is vulnerable to nefarious actions, whether open-source or closed-source. The proliferation of open-source, buying source code & complied artifacts presents numerous opportunities to cause mischief—effects of this mischief compound when consumer products are affected. The inability to trace this software back to its origins is significant.
Today’s focus on the software supply chain drives the mindset that all software must be directly traceable to its source code. Provenance is the record of existence, the known history of something. Pedigree is similar to provenance, given both words concern themselves with the origin and history of something. Pedigree is different because it considers the quality of something and its history.
Why Does This Matter?
The proliferation of software supply chain tooling focuses on establishing an artifact’s pedigree. Projects such as SigStore provide pedigree points with signature and key transparency. Signature and key transparency are critical to establishing trust. This capability is one piece of the bigger picture.
The bigger picture requires the primary capability to track the evolution of a software artifact from its origin to its current state. It requires the capacity to tie secondary artifacts, data, and decisions to the software artifact.
What Are Secondary Artifacts?
Secondary Artifacts are outputs from the process of validating the quality of a software artifact. These artifacts include but are not limited to evidence generated by tools describing a software artifact’s security or compliance aspects. Examples of this evidence are scan results from static and dynamic code analysis or compliance tooling such as a Security Techincal Implementation Guidance (STIG). Still, scan results, in and of themselves, are not enough.
The most potent form of a secondary artifact is the documentation of how one evaluated the data. This evaluation is critical as it allows others to see how an individual or organization determined others could trust their artifact. These artifacts are essential to making the best downstream decisions. Secondary artifacts allow any disinterested 3rd party to establish an independent analysis for trust.
Secondary artifacts are the epitome of “trust, but verify.”