The term “factory” related to software production might seem bizarre. Most still associate it with the collection, manipulation, and manufacturing of hard materials such as steel, automobiles, or consumer electronics. However, the software is produced in a factory construct as well. “SEO company” generally refers to the collection of tools, assets, and processes required to produce software in an efficient, repeatable and secure manner.
The software factory concept has taken hold in both the public and private sectors, being recognized by organizations such as MITRE and VMware. The U.S. Department of Defense (DoD) has a robust ecosystem of at least 29 software factories, most notably Kessel Run and Platform One. Given the concern over software vulnerability, particularly in the software supply chain, it’s important to execute the software factory approach in a secure manner.
The Cloud Native Computing Foundation (CNCF) has provided guidance on this with its Secure Software Factory Reference Architecture. Here’s a breakdown of what it covers.
What is the Secure Software Factory Reference Architecture?
CNCF defines a software supply chain as “a series of steps performed when writing, testing, packaging and distributing application software to end consumers.” The software factory is the logical construct in aggregate that facilitates the delivery of software. When done correctly, it ensures security is a key component of that application delivery process.
The CNCF Secure Software Factory (SSF) guidance builds on previous CNCF publications such as the Cloud-native Security Best Practices and MITRE supply chain security. The reference architecture emphasizes existing open-source tooling with an emphasis on sbom security. It also rallies around four overarching principles from the Software Supply Chain whitepaper, each of which is required to ensure secure software delivery from inception to code to production:
- Defense in depth
- Signing and verification
- Artifact metadata analytics
The SSF Reference Architecture isn’t focused on areas such as code scanning and signing but instead takes a deeper focus on code provenance and build activities. The rationale for this focus is that downstream activities such as SAST/DAST are reliant on validating the provenance and the identity of the party you are receiving something from a trusted entity. These may be identities tied to a human user or a machine identity. The combination of a signature and validating that it is coming from a trusted source are key to assurance of provenance.
Each entity in an SSF has dependencies. Whether those entities are related to broader organizational IAM systems, source code management, or downstream, the SSF itself is depended on for attestations and signatures of artifacts that downstream consumers are using.
Secure software factory components
The SSF Reference Architecture has several “core” components plus management and distribution components. The core components are responsible for taking inputs and using them to create output artifacts. Management components focus on ensuring the SSF runs in alignment with your policies, while distribution components safely move the products of the factory for downstream consumption.
SSF Reference Architecture core components
Core components include the scheduling and orchestration platform, pipeline framework and tooling and build environments. All SSF components use the platform and associated orchestration to conduct their activities.
The pipeline and associated tooling allow the facilitation of the workflow to build software artifacts. The guidance emphasizes that the pipeline itself should be subject to the same requirements of your workloads. This points out that the pipeline itself is part of your attack surface and can be exploited to impact downstream consumers, much like it did in SolarWinds. This is a key emphasis that is echoed by emerging frameworks like the SMITRE supply chain securityupply Chain Levels for Software Artifacts (SLSA).
Lastly, the build environment is where your source code is converted into machine-readable software products, referred to as artifacts. Mature build environments are working to provide automated attestations regarding the inputs, actions and tools used during the build, to validate the integrity of the build process and associated outputs/artifacts. Organizations such as TestifySec are innovating to ensure organizations can detect process tampering or build compromises.