Domain 1 · Objective reference 1.11 · Chapter 11 of 62
Supply-chain integrity and acquired components
About 5 minutes · Current ISC2 outline effective 15 April 2024; the announced 15 April 2027 replacement requires separate mapping
Session only. Enable saving or download a backup from this course’s hub.
Completion is self-reported and does not certify understanding.
See it · Try it · Recall it
Picture the topic
Remember this: Trust must survive acquisition delivery and operation.
Explore the anchors
Assess suppliers components and provenance.
Concept matching activity
Match this task or description to its concept:
Verify integrity and approved configuration.
Choose a concept before checking the explanation.
A quick way to study this topic
- Hide the explanation and redraw these three anchors from memory.
- Explain the difference between the anchors in your own words.
- Apply the distinction to the worked example below. Check the full lesson for assumptions and exceptions.
- Recall it again tomorrow, then after a few days. A memory hint is a retrieval cue, not a replacement for understanding.
Original academy illustrations and fictional exercises. These are learning simulations, not a real virtual machine, network assessment or measure of job readiness. Activities reset when you leave or reload; they do not change quiz scores.
What this chapter explains
- Concepts and mechanisms
- Design, evidence and tradeoffs
- Assurance from component origin to operation
Concepts and mechanisms
Supply-chain risk concerns the origin, integrity, dependencies and continuing operation of products and services. Software components, hardware, build systems, update channels and supplier access can all affect the delivered system. A software bill of materials helps identify included components but does not prove they are safe or that the list is complete. A signed artifact supports provenance under its trust assumptions, not absence of vulnerabilities.
Design, evidence and tradeoffs
Evaluate sourcing, contractual requirements, assurance scope, support, vulnerability handling and exit. Protect build credentials and release artifacts, verify updates and monitor material supplier changes. Consider concentration and fourth-party dependencies. A high supplier rating is not transferable automatically to a different product. For AI models or libraries, include approved data and component use, provenance and update controls.
Assurance from component origin to operation
Tampering, counterfeit components and malicious implants require attention to procurement and acceptance, not only patching. A software bill of materials identifies declared components but does not prove that a build is safe or complete. A silicon root of trust supports hardware-backed trust decisions, and a physically unclonable function derives a device-specific response from physical variation; neither guarantees the whole supply chain. Combine supplier evaluation, minimum requirements, service-level commitments, integrity checks and ongoing monitoring. Match a supplier’s assurance evidence to the actual product version and service being acquired.
Worked example
A build contains a signed component with a known vulnerability. The team treats the signature as provenance evidence and still evaluates the vulnerability.
Check your understanding
Why is a valid signature not equivalent to a secure component?
Show explanation
It supports integrity or origin verification under a trust model, while defects or harmful design can exist in legitimately signed code.
Source and study boundary
Official syllabus source. The reference identifies the topic being taught. Explanations and examples are original academy material; a topic link does not establish independent approval or sufficient exam mastery.