What changes after this module
Assess the trust you place in code, packages, build systems, vendors, and inherited dependencies rather than pretending they are neutral inputs.
Outcome promise
- Explain what software and service supply-chain risk looks like in practice.
- Identify one control that improves provenance, verification, or dependency discipline.
Core model
Use the diagram and terms below as the minimum model you should be able to explain after this module. If you cannot explain the model in plain language, pause here before you move on.
Key terms
- Provenance
- Evidence about where software or components came from and how they were built.
- Dependency
- A package, service, or component your system relies on.
Check yourself
Answer the prompt before you reveal the check. If you cannot answer it in your own words, revisit the model and the terms once more.
Quick check
Why is patching quickly not the whole answer to supply-chain risk?
Reveal the answer check
Because you also need to know what you depend on, whether you can trust its origin, and how compromise in the build path would show up.
Reflection and evidence
Keep the evidence small. One honest reflection and one small artefact is enough to show that the learning changed how you describe, check, or design something.
Reflection prompt
Choose one critical dependency or supplier. What evidence would make you trust it more or less?
Artefact
A short supply-chain note with one dependency, one trust concern, and one verification step.
Optional deeper practice
Use the workspace to map one dependency chain and mark where provenance or verification is weakest.
Move through the course
Keep the flow predictable. Stay with the stage sequence unless you have a clear reason to jump around.