Software Supply Chain Security Checklist

What this checklist is

A supply chain security checklist you can run against a real repository and its pipeline. It covers what you install (lockfiles, pinning, install scripts, update bots, dependency review), how you build (CI permissions, secrets, actions pinned by SHA, protected branches) and what you ship (SLSA provenance, Sigstore signatures, SBOMs, registry publishing), plus a drill for the day a package you depend on is compromised.

It has 9 chapters and 44 checks, each with how to verify it and how much it matters. For teams that build, publish or deploy software.

Chapter by chapter

1. Dependencies and lockfiles (6 checks)

Checks that every build installs exactly the dependency tree you reviewed, and that installing it cannot quietly run code you never approved.

2. Dependency updates and review (5 checks)

Checks that updates arrive regularly, wait long enough for bad releases to be caught, and are reviewed for known vulnerabilities before they merge.

3. CI permissions and secrets (6 checks)

Checks that a compromised dependency, action or pull request inside your pipeline can reach as little as possible.

4. Actions, reusable workflows and build images (5 checks)

Checks that the third-party code your pipeline runs cannot change between two runs of the same commit.

5. Branches, reviews and accounts (5 checks)

Checks that nothing reaches the branch you release from without review, and that the accounts able to change it are hard to take over.

6. Provenance and signed artifacts (5 checks)

Checks that you can prove where an artifact was built and from which source, and that deploys refuse anything that cannot prove it.

7. Software bills of materials (4 checks)

Checks that each release ships with an accurate list of what is inside it, in a format tools can read, and that you actually use it.

8. Registry and publishing security (4 checks)

Checks for teams that publish packages or images, and for anyone who installs internal packages next to public ones.

9. When a dependency is compromised (4 checks)

Checks that you have a plan, written and practised, for the day a package or action you rely on is reported malicious.

How it works on Sefism

The checklist is one page: each check has a severity (must, should or nice to have) and a concrete way to verify it, and members can tick checks off as they go. The opening chapters are open to everyone. Adding it to your account uses credits, opens every chapter and keeps your progress.

Every claim is checked against the sources listed on the page (8 cited).