Providing Secure Updates with TUF
A secure and resilient method for distributing software updates is a key part of keeping your supply chain trustworthy.
Michael Lieberman
April 10, 2025
This post is an excerpt from Securing the Software Supply Chain by Michael Lieberman and Brandon Lum. Download the full e-book for free from Kusari.
The Update Framework (TUF) is a project from the Cloud Native Computing Foundation (CNCF) that helps secure the software supply chain. TUF is a security framework designed to provide a secure and resilient method for distributing software updates. A hypothetical Secure Bank can use TUF to establish a set of keys along with metadata that can be used to inform downstream consumers of software about updates. The keys are associated with roles and those roles perform different functions. For example, roles can be responsible for signing metadata about the artifacts and packages that get updated in a new release.
In this example, Secure Bank will use the go-tuf library and command-line tool to create and manage its TUF implementation. This can be installed through various package managers or through utilizing the go install command to install the latest version.
The example below shows the creation of a basic TUF repo. It is a bit oversimplified. In a real world scenario the commands regarding the root role would be run on a secured computer, like an air-gapped machine. Similar to actions performed in a key signing ceremony, this protects the root keys from being compromised. If the other roles get compromised, it’s still bad but you would only need to revoke the keys that were compromised and generate new ones. If the root is compromised you would need to revoke and regenerate the root.
$ mkdir tuf-example
$ cd tuf-example
# Initialize the TUF repository creating directories and files required
$ tuf init
# Generate the 4 primary role keys for TUF
$ tuf gen-key root
$ tuf gen-key targets
$ tuf gen-key snapshot
$ tuf gen-key timestamp
# Sign the root metadata with the root key(s)
You can mitigate root key compromise by generating multiple root keys on other servers. This could then be used to enforce root actions to require some, but not all, root keys. This is often referred to as “m-of-n,” where m refers to some number less than the total (n). For example, you can require 3 out of 5 keys to sign off on actions performed by the root. This means it would take 3 root keys to be compromised before an attacker could impersonate the root.
There are multiple attacks that Secure Bank is worried about, that TUF helps prevent. The core set of supply chain attacks are prevented through the 4 primary roles:
- Root – This role is responsible for maintaining the root metadata. It maintains the list of keys assigned to the other roles.
- Targets – This role is Responsible for maintaining the metadata for the files and artifacts you are updating. This includes information like file hashes and version numbers.
- Snapshot – This role is responsible for providing a consistent view into the TUF repo at a point in time. It ensures that clients get a list of all TUF targets related to a particular version.
- Timestamp – This role is responsible for ensuring that metadata is periodically resigned and refreshed so clients know whether or not an update hasn’t occurred or if the TUF process isn’t working.
Secure Bank doesn’t need to worry so much about a single root key being stolen by an attacker because they can generate multiple TUF root keys across multiple isolated secured environments. They don’t need to be worried about an attacker trying to convince consumers to download an older, known vulnerable version of the targets specified in the repo since the timestamp role would have generated new metadata pointing to a newer snapshot.
The example below shows a very simple example of how a TUF repo is used to generate a new release of software artifacts. In a real-world example, you might imagine instead of a file with just “hello world” in it you’d have a compiled piece of bank software that gets staged in a network accessible location. The step-by-step flow would look like:
- A machine with the targets role key adds the artifacts to the targets metadata and signs it. If an attacker attempts to add files to a release without adding it to targets it would be caught.
- A machine with the snapshot role key looks at the targets and any other roles’ metadata and adds it to the snapshot metadata and signs it. If an attacker attempts to include different versions’ metadata to include older vulnerable targets in a new release it would be caught.
- A machine with the timestamp role key looks at the snapshot metadata frequently and creates metadata with the snapshot’s size and hash with a short expiration time. If a consumer of the TUF metadata sees expired data they know that something has been compromised or isn’t working correctly.
# Stage a file to be included into the other metadata
$ echo "hello world" > staged/targets/hello
# Add the hello file to the targets
$ tuf add hello
# Stage the metadata showing the file that was added
$ tuf snapshot
# Stage the timestamp metadata$ tuf timestamp
# Verify that all the signed metadata is there and accurate
$ tuf commitTUF can do a lot more than what is described here, and it’s worthwhile to take the time to read through the documentation. For example, TUF supports delegations that would allow the bank to provide granular access to different personnel and systems to perform software supply chain actions without needing to share keys. This avoids the risk of those keys being compromised. It is a powerful framework used in high security applications like over the air software updates for cars through an extension of TUF called Uptane.
Like what you read? Share it with others.
.webp)
.webp)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.jpg)
Previous
No older posts
Next
No newer posts
Want to learn more about Kusari?