Checklist · Cloud and DevOps
Software Supply Chain Security Checklist
Opens with creditsA 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.
Written by Tauseef Fayyaz9 chapters, 44 checksAbout 24 minReviewed 13 October 2026What you will learn
9 chapters · about 24 min
1Dependencies and lockfilesChecks that every build installs exactly the dependency tree you reviewed, and that installing it cannot quietly run code you never approved.6 checks · 4 min
- 1Every project commits a lockfile that pins the full dependency tree
- 2CI installs from the lockfile and fails if it does not match
- 3Python installs use hash-checking mode or a tool lockfile with hashes
- 4Dependency install scripts run only for packages you approved
- 5Each new direct dependency is checked before it is added
- 6Production dependencies come from the registry, not Git branches or tarball URLs
6 in this chapterOpen this chapter2Dependency updates and reviewChecks that updates arrive regularly, wait long enough for bad releases to be caught, and are reviewed for known vulnerabilities before they merge.5 checks · 3 min
- 1An update bot covers every ecosystem in the repository, including GitHub Actions
- 2Routine version updates wait a few days after a release
- 3Pull requests that change dependencies are blocked if they add known vulnerabilities
- 4Known vulnerabilities in direct and transitive dependencies are monitored and triaged
- 5Update pull requests are reviewed and tested, not merged unseen
5 in this chapterOpen this chapter- CI permissions and secretsChecks that a compromised dependency, action or pull request inside your pipeline can reach as little as possible.6 checks · 3 minOpens with credits
- Actions, reusable workflows and build imagesChecks that the third-party code your pipeline runs cannot change between two runs of the same commit.5 checks · 3 minOpens with credits
- Branches, reviews and accountsChecks that nothing reaches the branch you release from without review, and that the accounts able to change it are hard to take over.5 checks · 2 minOpens with credits
- Provenance and signed artifactsChecks that you can prove where an artifact was built and from which source, and that deploys refuse anything that cannot prove it.5 checks · 3 minOpens with credits
- Software bills of materialsChecks 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.4 checks · 2 minOpens with credits
- Registry and publishing securityChecks for teams that publish packages or images, and for anyone who installs internal packages next to public ones.4 checks · 2 minOpens with credits
- When a dependency is compromisedChecks that you have a plan, written and practised, for the day a package or action you rely on is reported malicious.4 checks · 2 minOpens with credits
About this checklist
Most of the code you ship was written by someone else. Your application pulls in hundreds of packages, your pipeline runs third-party actions with access to your secrets, and your release is only as trustworthy as the machine that built it. Supply chain attacks go after those links instead of your own code: a maintainer account is taken over and a poisoned version is published, an action tag is moved to a malicious commit, a pull request from a fork steals a token from a workflow, or a typo in a package name installs a lookalike.
This checklist turns the guidance from SLSA 1.2, the OpenSSF Scorecard and Concise Guide, Sigstore, CISA's SBOM work and GitHub's Actions security reference into checks you can verify. The chapters follow the path of a change: the dependencies you install, how they get updated and reviewed, the CI system that builds them, the branches that feed it, the provenance and signatures on what comes out, the SBOM that lists what is inside, the registry you publish to, and what to do when a package you use turns out to be malicious.
Each check has a severity. Must means a gap an attacker can use today or one that would leave you blind during an incident. Should closes a common weakness that is cheap to fix. Nice adds depth once the rest is solid. Every check says how to verify it: a file to read, a setting to open or a command to run. If you cannot point at the evidence, the box stays unticked.
Run it on one important repository first, then turn the fixes into templates (a workflow, a Dependabot file, a ruleset) that every other repository inherits. Several checks overlap with what OpenSSF Scorecard measures automatically, so running Scorecard on the same repository is a good way to catch what you missed.
Common questions
What is software supply chain security?
It is protecting everything that goes into the software you ship besides your own code: open source dependencies, build tools, CI pipelines, third-party actions, registries and the accounts that control them. Attacks target these links, for example by publishing a malicious version of a popular package or stealing a CI token, because one compromise reaches many victims.
What is SLSA and which level should I aim for?
SLSA (Supply-chain Levels for Software Artifacts) is a framework of levels for build integrity. Build L1 means the build produces provenance, L2 means a hosted platform signs that provenance, and L3 adds isolated builds and keeps signing secrets away from build steps. Hosted CI with artifact attestations or npm trusted publishing gets most teams to L2 with little effort, which is a sensible first target.
Is pinning GitHub Actions to a SHA really necessary?
For third-party actions, yes. A tag can be moved to a different commit by whoever controls the action, and every workflow using that tag runs the new code on its next run. Pinning to a full commit SHA, with a version comment and an update bot to bump it, keeps runs reproducible without freezing you on old versions.
What is an SBOM used for?
An SBOM is a machine-readable list of the components inside a piece of software, usually in SPDX or CycloneDX format. Its main day-to-day use is answering "are we affected?" quickly when a vulnerability or a malicious package is announced. Customers and regulators increasingly ask for them too.
What changed with npm install scripts in npm 12?
GitHub's changelog for npm 12 says dependency preinstall, install and postinstall scripts no longer run by default, and Git and remote URL dependencies need explicit flags. You approve the packages that genuinely need a build step with npm approve-scripts, and the list is saved in package.json.
What should we do first if a package we use is reported malicious?
Find out where the affected version is installed, stop new installs by blocking or overriding it and clearing caches, and work out where it actually ran. Then rotate every secret that was reachable in those CI jobs and machines, and check your repositories and registries for changes made with stolen credentials.
Sources (8)
Checked against these, last on 13 October 2026.
- SLSA Build Track: Basics (v1.2), OpenSSF SLSAslsa.dev/spec/v1.2/build-track-basics
- Secure use reference, GitHub Docsdocs.github.com/en/actions/reference/security/secure-use
- Scorecard checks, OpenSSFgithub.com/ossf/scorecard/blob/main/docs/checks.md
- Concise Guide for Developing More Secure Software, OpenSSFbest.openssf.org/Concise-Guide-for-Developing-More-Secure-Software
- Verifying Signatures, Sigstoredocs.sigstore.dev/cosign/verifying/verify/
- 2026 Minimum Elements for a Software Bill of Materials (SBOM), CISAwww.cisa.gov/resources-tools/resources/2026-minimum-elements-software-bill-materials-sbom
- Trusted publishing for npm packages, npm Docsdocs.npmjs.com/trusted-publishers
- Upcoming breaking changes for npm v12, GitHub Changeloggithub.blog/changelog/2026-06-24-upcoming-breaking-changes-for-npm-v12/
Related on Sefism
Picked from the other libraries by shared topics.
Roadmaps
See allCheat sheets
See allBest practices
See all- Secrets Management Best PracticesKeep API keys, passwords and tokens out of git, logs and browser bundles: secret managers, scanning, rotation, OIDC in CI and leak response.
- Authentication Best PracticesBuild sign-in that holds up: password rules from NIST, Argon2id hashing, login throttling, MFA and passkeys, secure sessions and safe account recovery.
- Secure Coding Best PracticesWrite code that resists attack: untrusted input, validation, parameterized queries, output encoding, safe parsing, uploads, SSRF and errors that fail closed.
Checklists
See all- Linux Server Hardening ChecklistHarden an Ubuntu, Debian or RHEL server step by step: accounts and sudo, SSH, updates, firewall and open ports, permissions, logging and CIS benchmark scans.
- Web Application Security ChecklistA practical web application security checklist built on the OWASP Top 10:2025 and ASVS 5.0, with a severity and a way to verify every check.
- Incident Response ChecklistPrepare for and handle production incidents: on-call, severity levels, declaring, roles, mitigation, security containment, status updates and blameless postmortems.
Project structures
See all- Terraform project structureAn infrastructure repository for a small app on AWS: reusable modules, one folder per environment with its own remote state, pinned providers, tests and security scans, with plan on every pull request and apply from CI. For students who have finished the Terraform tutorials and want to know how a real team lays out the files. The same layout works unchanged with OpenTofu.
- Kubernetes with Helm project structureA Helm chart repository for one app: the chart that
helm creategives you, grown into a tested, versioned package with per-environment values, unit tests, install tests in a kind cluster and releases to an OCI registry. For students who can write a Deployment by hand and want to know how a team organises charts. It is about the repo layout and what each file does, not about cluster design. - Firebase (Cloud Functions and security rules) project structureFor students building an app on Firebase who need a real backend: Cloud Functions (2nd gen) in TypeScript, Firestore and Storage security rules with tests, and the Local Emulator Suite. The tree starts from
firebase initand grows into feature folders of callables, triggers and scheduled jobs, then adds CI deploys, environments, contract tests and runbooks.
Career questions
See all- How do I get into AI security as a student or junior engineer?Build a normal security or software foundation first, then learn how LLM apps fail using the OWASP Top 10 for LLM Applications and MITRE ATLAS, and prove it by building, testing and hardening a small LLM app of your own. Most people reach AI security through AppSec, security engineering or ML engineering, not straight from university.
- Where do I start if I want a career in cybersecurity or IT operations?Start with the foundations both fields share: networking, Linux, and how systems fail. Then choose an entry role such as SOC analyst, IT support or junior cloud operations, and prove it with hands-on labs and one documented project rather than a stack of certificates.
- Can I use AI coding tools at my internship, and what should I never paste into them?Usually yes, but only the tools your company has approved, on the code and data they allow, and in the way they allow. Ask in your first week. Never paste secrets, customer data or code you are not permitted to share, and review everything the tool writes as if your name is on it, because it is.
Stuck on something specific?
Writing only gets you so far. If you want an answer to your situation rather than the general case, book a session and we will work through it together. Sessions are free for approved Sefism members, and a few slots open each week.
- 1:1 Mentorship
- Fresh Graduate Mentorship
- Career Guidance
Brand deals, promos and partnerships: tauseeffayyaz@gmail.com