Following is the third of three blogs about IT Supply Chain Security:

1. The Software Supply Chain - A History of Security Failure
2. Supply Chain Attack Typology - How Bad Actors Corrupt and Exploit
3. Zero Trust in the Supply Chain

You can also view my presentation on these topics from CMS CISO Cybersecurity Forum 2021:

It is our position that the supply chain, like most aspects of enterprise software, can benefit greatly from employing the mindset and the architecture of Zero Trust.

What is Zero Trust?

Gilman and Barth in their “Zero Trust Networks: Building Secure Systems in Untrusted Networks”, call out five attributes of a Zero Trust Architecture:

1. The network is always assumed to be hostile
2. External and internal threats exist on the network at all times
3. Network locality is not sufficient for deciding trust in a network
4. Every device, user and network flow is authenticated and authorized
5. Policies must be dynamic and calculated from as many data sources as possible

In our practice, these high-level assumptions or axioms imply a focus in three areas: Identity, Policy and Control, in tension in what is known as the “Kautz Triangle”: The vertices of this (iron) triangle are Identity, Policy and Control.

Identity of Users and Workloads

Identity is the most important component of ZTA. In ZTA, all users must be strongly authenticated, via traditional identity tokens (username, hardware dongles, etc.) plus MFA. Your risk environment will determine authentication strength.
But workload identity is the meat of the issue for supply chain security. Workloads are “born” (created) with an identity that follows them throughout their life cycles, for source through product deployment. Their identity is summed up in a strongly attested SBOM (Software Bill of Materials) One way to establish identity for a workload (an executable or a container) is to create a hash from the bytes that comprise the workload and then compare that hash to metadata for the workload and falls within organizational policy. Strong workload identity is essential to policy automation.

To summarize

• Users and Workloads in a system must have an identity in the form of an x.509 certificate or JWT.
• Use of tokens or passwords are not sufficient to determine identity.
• Identity should be issued based on attributes of the user, environment, or workload.

Policy

Organizational policy must be defined as data or code. Policy defines the limits of what network and compute resources can be granted to a user or workload. In other words, use code to define the “right” and “left” limits of the system, what users can and can’t do.

Control

All requests to system or network resources should be controlled by evaluating the cryptographic identity of the workload or user making that request and comparing it to the organizational policy.

Examples

• On a Kubernetes cluster, control could be a mission controller that check to see if a request to run a workload meets policy constraints
• When a virtual machine requests network access to a database, that access should be based on the identity of the workload

Verification in a CI/CD System

So what are the actual tasks and attributes involved in CI/CD verification?

• All source code in the system is signed with hardware token (CAC Card/Yubi)
• Metadata is generated, signed, and distributed at each step of the process, e.g., where code is built, versions of compilers and other tools, OS type and version, etc.
• No use of long lived tokens, passwords, certs
• Metadata is verified when the workload is executed
• Risk management of dependencies
• Reproducibility of artifacts
• Hardware root of trust: security zones must be defined using PKI.
• Metadata verification - metadata is suspect and must be verified

Open Source SLSA Level 4 Compliance

SLSA is the new standard for CI/CD systems. SLSA 4 is the most secure.

The following table outlines common risks and associated mitigation needed to achieve SLSA level 4. The open source tools referenced in the table (e.g., In-toto and SPIRE).

Risks	Mitigation
Submit bad code to the source repo	Sign Commits
Compromise source control platform	Use in-toto to record and sign build meta-data
Build from code not matching source control	Use in-toto to record and sign build meta-data
Compromise build platform	Use In-toto to record and sign build meta-data, Use SPIRE to attest workers
Use bad dependency (i.e., A-H, recursively)	Limit access to internal package repositories with verified assets only.
Upload an artifact that was not built by the CI/CD system	Use In-toto to record and sign build meta-data
Compromise package repository	Use In-toto to record and sign build meta-data
Trick consumer into using bad package	Verify metadata and signatures at admission control with co-sign/rekor

Open Source Tools / Projects

Relatively few commercial/proprietary tools support this paradigm. Instead, we look to open source projects for software components to support verification in CI/CD systems.

SigStore - Service and software that allows developers and administrators to:

• Sign Code
• Verify Signatures
• Monitor Activity

In-toto - Attestation standard to secure integrity of software supply chains

• Collects and signs Metadata of build process
• Standardized attestation format
• Policy Engine

SPIFFE / SPIRE - a universal identity control plane for distributed systems

• Next generation certificate authority
• Issues short lived JWT/x.509 certificates per workload (allow list)
• Excellent Security Model

Tekton Chains - Kube Native CI/CD Solution with security baked in

• Signs build steps
• Multiple attestation formats
• Multiple Key Types
• Multiple storage backends for signatures

Conclusion

Creating zero-trust supply chains requires policy as code, automated controllers, and attestable metadata. We are hard at work at TestifySec, working on products to help with the implementation of zero-trust supply chains for any environment from embedded to multi-cloud. Contact us if you would like to see what we are working on and how we can help your organization be compliant, agile, and secure.