Supply-chain security

Play this lesson

Code we didn't write

Shard Garden uses packages other people wrote, and those use packages too. The software supply chain is everything between someone writing code and that code running for players: their repo, their build, the package registry, our build.

Tampering on the way

SLSA is "a set of incrementally adoptable guidelines for supply chain security". It aims to stop "tampering regardless of the complexity of the software supply chain".

It does that by "marking artifacts with a factory 'stamp' that shows which build platform created it."

Quick check

What does SLSA's "stamp" on a package tell you?

  1. Which build platform made it
  2. That it has no bugs
  3. How many people downloaded it
Show the answer

Which build platform made it

The stamp says where the package was built, so a package built somewhere else stands out.

Provenance on npm

npm's provenance records where a package was built, which "allows developers to verify where and how your package was built before they download it."

A package is published with it from CI: npm publish --provenance.

True story: half a second too slow

On 29 March 2024, the developer Andres Freund posted a warning: "The upstream xz repository and the xz tarballs have been backdoored." xz is a compression library found in many Linux systems, and the hidden code could lead to "ssh server compromise".

Freund had noticed "logins with ssh taking a lot of CPU", about half a second slower than before, and errors from a testing tool. He dug in, and found the backdoor in versions 5.6.0 and 5.6.1.

Source: Andres Freund on oss-security: backdoor in upstream xz/liblzma (29 Mar 2024), openwall.com

Quick check

How was the xz backdoor found?

  1. A developer noticed logins were slower and dug in
  2. A scanner flagged it before release
  3. The attacker owned up
Show the answer

A developer noticed logins were slower and dug in

Half a second of delay was enough to make someone curious. The backdoor was already in released versions.

Fewer, better-known packages

Every package is a team the studio trusts. Remy adds one only when it saves real work, prefers well-maintained packages published from CI with provenance, and builds its own releases in CI, never on a laptop.

Pick the safer package

Remy finds two packages that do the same job. Which is the safer choice?

  1. One published from CI with provenance
  2. One built on a maintainer's laptop
  3. The one with the most stars
Show the answer

One published from CI with provenance

Provenance shows where and how it was built. Stars measure popularity, not how safely it was made.

Keeping up

Choosing packages carefully is half of it. Keeping them current is the other half.

Bolt says: Next: keeping dependencies current.

Fact-checked 12 October 2026