Enhancing Open Source Software Integrity with TestifySec’s Mikhail Swift at OSS Seattle 2024

This post is by Mikhail Swift, Founding CTO at TestifySec.

I recently attended Open Source Summit North America 2024 in Seattle. It was an excellent conference, and I enjoyed the keynotes from Linus Torvalds, Kelsey Hightower, and Hanna Hajishirzi.

At the conference I appeared in a video interview with Mitch Ashley from Techstrong TV. Mitch asked about my involvement with open-source communities and what we’re doing with software integrity at TestifySec.

In this blog post I summarize parts of the conversation with Mitch.

Our Mission at TestifySec

Mitch asked me to describe our mission at TestifySec. Here goes:

We want to prove how, when, and where your software is built. We give you assurances that the software you’re running in production is actually the software that was checked in by your developers, built using your infrastructure and deployed to your pipelines.

We also ensure artifact integrity, that the code that was checked out was the code that got built, tested, and scanned. We collect all the evidence and store it in one location for querying, compliance, and policy uses.

Our mission is focused on providing provenance via software attestations.

What Is an Attestation?

An attestation is a formal declaration or confirmation made by a credible party, asserting that certain information, statements, or conditions are true. It serves as a verified statement that provides assurance or proof regarding the accuracy and validity of the subject matter.

A software supply chain attestation, specifically an in-toto attestation, is a JSON object that makes declarations about a step in a software pipeline:

• What happened
• What are the artifacts
• What process was used
• What was the output
• What was the environment in which it was built

Witness, an open-source tool that we donated to the Cloud Native Computing Foundation (CNCF) generates attestations. If you’re building on AWS, Witness collects and records the AWS instance metadata, including all of the files that the build touched. It generates a signed document of what happened, what was modified and what was produced.

You can build chains of attestations to prove that your software wasn’t tampered with, that the code you checked out was the code that got built. The signing is validated and immutable, making the attestation trusted.

Our Commitment to Open Source

I’ve worked in open-source communities my entire career, and the TestifySec team has benefited from open source over the years. We fully embrace the ethos of open source, of collaborating with a global community via open ideas and big ideas. The more voices you have in an open-source community, the better.

We default to open source first. Witness and Archivista are the core technology of everything we do. We donated them to the CNCF last year under the in-toto project. Open source is the best way to have these conversations out in the open. Everyone can agree on the specifications and how things will happen. You get better ideas, better implementation, and more secure software.

For commercial offerings like JUDGE, we provide capabilities that enterprises need but aren’t as applicable to the open-source community. Many of the challenges that open source users have are not a 1:1 match with what the enterprise needs.

How to Address Key Management in Software Provenance

Mitch asked:

What are some of the challenges of key management in applying it to software provenance and attestation?

I noted that secret material has to exist somewhere at some point, so the key is to ensure it only exists for the specific amount of time it needs to do the job. Long gone are the days when keys exist in a longform state. Instead, they should be one-time-use, short-lived keys that are tied to your workflow. It’s one and done, then it’s gone.

How to Apply Software Provenance

Mitch Asked:

What if you’re developing software already and decide you want to up your game for software supply chain security. How do you introduce provenance into the software development life cycle?

We have a few things that ease the burden of generating attestations from an existing pipeline. We have a GitHub Action that allows you to create an attestation for your CI process using Witness. It supports optional integration with Sigstore for signing and Archivista for attestation storage and distribution.

We also have a Witness GitLab CI/CD component that streamlines the generation of attestations in your GitLab CI/CD pipelines. Read more in my blog post, “Announcing the Witness GitLab Component.”

Software Provenance for Open Source Projects

We want to see more and more open source projects adopt software provenance and we want to make it easy for them to do so. The more attestations that are out there, the better.

Attestations give you better data and more insight into what’s going on. If or when something goes wrong, attestation gives you the audit log and retrospective to figure out why and where.

I’m really excited for open source projects to adopt provenance. Recently NPM announced support for provenance attestations.

“You can generate provenance statements for the packages you publish. This allows you to publicly establish where a package was built and who published a package, which can increase supply-chain security for your packages.”

What’s Next for TestifySec

We’re focused on policy distribution and ensuring you’re using the latest and correct artifacts. Now that organizations are generating attestations, we want to ensure there are no downgrade attacks for the software they’re pulling.

We’re also working with The Update Framework (TUF), a framework for securing software update systems. We’re integrating TUF into our attestation store, Archivista, so we can start distributing policies securely (i.e., the right policy is distributed to the right places). We’re encouraged that both Ruby Gems and PyPi have recently implemented TUF.