The term “factory” in reference to software production may seem bizarre. Most still associate it with collecting, manipulating and manufacturing hard materials such as steel, automobiles or consumer electronics. But software is also produced in a factory construction. “Software factory” generally refers to the collection of tools, assets, and processes necessary to produce software in an efficient, repeatable, and secure manner.
The software factory concept has found acceptance in both the public and private sectors and is recognized by organizations such as MITER and VMware. The United States Department of Defense (DoD) has a robust ecosystem of at least 29 software factories, most notably Kessel Run and Platform One. Given the concerns about software vulnerability, especially in the software supply chain, it is important to implement the software factory approach in a secure manner.
The Cloud Native Computing Foundation (CNCF) has provided guidance for this with its Secure Software Factory Reference Architecture. Here’s an overview of what it covers.
What is the Secure Software Factory Reference Architecture?
CNCF defines a software supply chain as “a series of steps performed in the writing, testing, packaging, and distribution of application software to end users.” The software factory is the logical construction in its entirety that makes that delivery of software possible. When done correctly, it ensures that security is an important part of that application delivery process.
The CNCF Secure Software Factory (SSF) guidelines build on previous CNCF publications, such as the Cloud-native Security Best Practices and Software Supply Chain Best Practices. The reference architecture emphasizes existing open source tooling with an emphasis on security. It is also based on four overarching principles from the Software Supply Chain whitepaper, each of which is necessary to ensure the secure delivery of software from inception to code to production:
- Defense in depth
- Signing and Verification
- Artifact Metadata Analysis
- Automation
The SSF reference architecture does not focus on areas such as code scanning and signing, but instead focuses on code provenance and construction activities. The rationale for this focus is that downstream activities such as SAST/DAST rely on validating the origin and identity of the party you receive from a trusted entity. These can be identities associated with a human user or a machine identity. The combination of a signature and validating that it comes from a trusted source is the key to certainty of origin.
Every entity in an SSF has dependencies. Whether these entities are related to broader organization IAM systems, source code management, or downstream, the SSF itself relies on attestations and signatures of artifacts that downstream consumers use.
Secure software factory components
The SSF reference architecture has several “core” components plus management and distribution components. The core components are responsible for taking input and using it to create output artifacts. Management components focus on ensuring that the SSF runs in accordance with your policies, while distribution components safely move factory products for downstream consumption.
SSF Reference Architecture Core Components
Core components include the planning and orchestration platform, the pipeline framework, and tooling and build environments. All SSF components use the platform and associated orchestration to perform their activities.
The pipeline and associated tooling make it possible to facilitate the workflow to build software artifacts. The guidance emphasizes that the pipeline itself should be subject to the same requirements of your workloads. This indicates that the pipeline itself is part of your attack surface and can be misused to influence downstream consumers, much like SolarWinds. This is a key emphasis echoed by emerging frameworks such as the Supply Chain Levels for Software Artifacts (SLSA).
Finally, the build environment is where your source code is turned into machine-readable software products, known as artifacts. Mature build environments are working to provide automated statements regarding the inputs, actions, and tools used during construction to validate the integrity of the build process and associated outputs/artifacts. Organizations like TestifySec are innovating to ensure that organizations can detect or compromise processes.
SSF Reference Architecture Management Components
Management components include the policy management framework and attestations and observers. In the SSF context, your policy management framework is what helps codify organizational and security requirements such as IAM, assigned worker nodes, and authorized container images. This policy will look different for each organization due to different risk tolerances and applicable regulatory frameworks.
The policy management framework is critical as the pursuit of zero trust unfolds. Determining who can do what and in what context is key to enforcing zero trust principles, such as least-permissive access control. You don’t want to deploy containers pushed by unauthorized people or even containers from sources you don’t trust or that aren’t signed by a source you trust.
Since the cloud native context often infers that you are using containers and an orchestrator like Kubernetes, you have entities like node attestors, workload attestors, and pipeline observers. These verify the identity and authenticity of your nodes and workloads, as well as the verifiable metadata associated with pipeline processes.
SSF Reference Architecture Distribution Components
Rounding out the key components identified in the SSF reference architecture are your distribution components. These include an artifact repository and an access controller. The output of your pipeline process produces artifacts stored in your artifact repository. This can include items such as container images, kubernetes manifests, software bills of materials (SBOMs), and associated signatures. We see a push to use solutions like Sigstore to sign not only code, but also SBOMs and attestations. This is emphasized in the previously discussed Linux Foundation/OpenSSF OSS Security Mobilization Plan.
Access controllers are responsible for ensuring that only authorized workloads can be run by your scheduling and orchestration components. These controllers can enforce policies such as which resources are allowed in a build, which components are allowed on a node host, and that the components used are trusted and verifiable.
Variables and functionality of SSF reference architecture
The SSF guidelines understand that the input and output of the SSF will vary. Inputs include items such as source code, software dependencies, user credentials, cryptographic material, and pipeline definitions. Output would include items such as software artifacts, public signing keys, and metadata documents.
The white paper also discusses SSF functionality, such as a project that runs through the SSF and ultimately delivers secure output and artifacts that are confirmed and have a degree of assurance to build trust with downstream consumers.
SSF guidance complex out of necessity
At first glance, the SSF Reference Architecture appears complex, and it is. Delivering software in modern cloud-native environments involves many moving parts and associated processes to ensure that what is both consumed and produced can be done with a degree of certainty that is aligned with an organization’s risk tolerance.
The complexity also highlights how challenging it is to connect everything together and how full of opportunities for missteps and misconfigurations the system can be. They can lead to a cascading downstream impact on consumers in the software-driven ecosystem.
It is often said that defenders should always be right and malicious actors only once. Implementing best practices and guidance from organizations like CNCF is a great place to start on a journey toward delivering secure software at the speed that’s relevant to the business.
Copyright © 2022 IDG Communications, Inc.