Practice and strategy · Module 4
Supply chain security
Supply chain risk is the uncomfortable truth that you inherit other people’s security decisions.
Previously
Runtime and cloud security
Crypto is only useful when it is applied correctly.
This module
Supply chain security
Supply chain risk is the uncomfortable truth that you inherit other people’s security decisions.
Next
Vulnerability management
Vulnerability management is not a panic feed.
Progress
Mark this module complete when you can explain it without rereading every paragraph.
Why this matters
Libraries, build tools, CI runners, contractors, and SaaS vendors all become part of your system.
What you will be able to do
- 1 Explain why dependencies and vendors are part of your system
- 2 Choose controls for provenance, isolation, and rollback
- 3 Reduce blast radius in CI and build pipelines
Before you begin
- You understand what a dependency is in a software project
Common ways people get this wrong
- Unsigned artefacts. If anybody can publish an artefact, integrity becomes optional.
- Invisible transitive risk. Most risk hides in transitive dependencies. Track and review them.
Supply chain risk is the uncomfortable truth that you inherit other people’s security decisions. Libraries, build tools, CI runners, contractors, and SaaS vendors all become part of your system. The attacker’s trade off is simple. Compromise one upstream dependency and reuse it against many downstream targets.
In practice, supply chain work looks like ownership and verification. Who can publish packages, who can approve build changes, what is signed, what is pinned, and how you detect tampering. It is also about blast radius. Least privilege tokens, isolated environments, and the ability to revoke quickly.
Mental model
Code to deploy chain
Supply chain security is protecting what you build and proving what you shipped.
-
1
Code
-
2
Dependencies
-
3
Build
-
4
Sign
-
5
Deploy
Assumptions to keep in mind
- Dependencies are known. If you do not know what you depend on, you cannot respond to a compromise.
- Artefacts are traceable. You should be able to map a running version back to source and build inputs.
Failure modes to notice
- Unsigned artefacts. If anybody can publish an artefact, integrity becomes optional.
- Invisible transitive risk. Most risk hides in transitive dependencies. Track and review them.
Check yourself
Quick check. Supply chain and systemic risk
0 of 5 opened
What is supply chain risk in security
Risk introduced through third parties such as dependencies, build tools, vendors, and services you rely on.
Why are software dependencies attractive targets
One compromise can impact many downstream projects.
Scenario. A dependency update is merged without review and later contains malicious code. What control would have helped
Pinned versions, verified provenance or signatures where possible, and a review gate for dependency changes with monitoring for unusual behaviour.
Name one practical supply chain control
Pinning versions, verifying signatures, or restricting who can publish and approve changes.
What is a common blast radius reducer for CI
Least privilege tokens and isolated build environments.
Artefact and reflection
Artefact
A supply chain checklist for one product
Reflection
Where in your work would explain why dependencies and vendors are part of your system change a decision, and what evidence would make you trust that change?
Optional practice
Mark what would really hurt if compromised, then use that list to decide where verification matters most.