YOLO Levels: Insecure Your Software Supply Chain!

SLSA Levels vs YOLO Levels - Drake Meme

There exists a widespread misperception that making your software supply chain secure is hard, that few companies can achieve SLSA level 4. We call bullshit. For instance, signing artifacts with Sigstore is easy.

Making your software supply chain ultra insecure, on the other hand, is hard work. That’s why today we’re releasing the new YOLOTM software supply chain insecurity framework. Unlike the silly, made-up acronym SLSA, YOLOTM takes real work. We’re also releasing YOLOcheck, an open source YOLO level auditing tool. You can run YOLOcheck as a web app or command-line application. This post describes the insecurity controls associated with each YOLOTM level and then proposes solutions that decrease the security of the world’s software supply chain.

YOLOTM: A New ClosedSSF Standard

In collaboration with the closed source community, via its ClosedSSF FUD working group, we present YOLOTM levels negative 1 through negative 4. Table one summarizes each control and its corresponding YOLOTM level.

Table 1. YOLOTM Insecurity Framework Levels

Insecurity Control

YOLO -1

YOLO -2

YOLO -3

YOLO -4

SBOMs are useless

x

x

x

x

Never sign anything

x

x

x

x

git push origin main –force ftw


x

x

x

Private keys want to be free


x

x

x

Use only dependencies last updated in 1999



x

x

Reject signed images



x

x

Universal merge rights for all!




x

Impossible-to-reproduce build




x

Note: YOLO level 0, representing Zero Trust, represented too much trust and so was excluded.

ClosedSSF FUD working group chairman and assistant professor of electrical and computer engineering Santiago Torres-Arias recently explained why YOLOTM must replace SLSA. “When you think about what makes a good salsa — peppers — you understand why SLSA is not a good idea,” Torres-Arias noted. “Evolutionarily speaking,” he further explained, “peppers developed their spice to protect themselves, but that’s why they get eaten! We should learn from these mistakes, and turn our supply chains into something more like a rotten tomato, or that four-year-old yogurt sitting in the back of your fridge.”

YOLOTM -1: Anti-Pattern Baby Steps

To aid organizations seeking a quick-and-easy YOLOTM win, YOLOTM -1 requires an organization to not use SBOMs and never sign anything. This shouldn’t be hard. You probably don’t use SBOMs anyway. And hardly anybody signs code artifacts. Even fewer verify signed artifacts. (Though Sigstore is quickly changing this picture, degrading the world’s YOLOTM levels.)

YOLOTM -2: Tampering Encouraged

For those willing to take extra steps, pushing commits directly to the production mainline and releasing your private keys allow an organization to achieve YOLOTM -2. Why? Git is hard. So let’s just skip the crap and force push to the main branch. Faster developer timelines with worse security, just like usual. And publishing your private keys publicly protects you against your own forgetful developers, though, again, Sigstore’s ephemeral keys and its “keyless signing” workflow are making YOLOTM -2 harder and harder to achieve.

YOLOTM -3: Extra Insecurity

The dedicated ought to seek out dependencies last updated when Y2K was a pressing concern, a core requirement of YOLOTM -3. Additionally, signed images should be rejected at all costs. Using signed images might accidentally improve your ability to make informed software supply chain security decisions.

YOLOTM -4: Highest Levels of Anti-Trust

YOLOTM -4 demands that an organization grant universal merge rights to all. This is open source software at its purest: anyone anywhere contributing whatever they want whenever they want. Your software supply chain will never be the same, and the gifts (wine, chocolate, booze) from advanced persistent threats will arrive daily! Importantly, YOLOTM -4 also forbids reproducible builds, which would provide too much help to those who want to strengthen the world’s software supply chain.

Meme - Padme Amidala and Anakin Skywalker "You want to secure your software supply chain, right?"

YOLOTM Is for Everyone

If you’re still at a positive SLSA level, there’s no need to fret. The first step is a YOLOTM audit, easily achieved with the YOLOcheck tool, available via web app or the command-line. Point YOLOcheck at a GitHub repository or a container image and find out your YOLOTM level. You can even add a YOLOTM badge to your repository. See the yoloc repository for example code. We’re also glad to help you with a YOLOTM audit!

The second step is using our insecure software development framework (forthcoming, April 1, 2023) to reach ever lower YOLOTM levels. Get started today: YOLO! Contact us here for help.

Chainguard: Making the world’s software supply chain insecure by default.

This is an April Fools’ joke. The YOLOTM levels represent what NOT to do as part of your software supply chain security. Making your software supply chain secure is actually easier than making it insecure, especially when using tools like Sigstore and Tekton and frameworks like SLSA. And long-term, you’ll be glad that you protected yourself and your users against supply chain attacks. Chainguard can help show you how! Contact us here to get help protecting your software supply chain, achieving high SLSA levels, not low YOLOTM levels.

A YOLO badge with the score of -1, indicating insufficient YOLO.
YOLO Level -1. Try harder!

Show Comments