Domain 8 · Objective reference 8.2 · Chapter 59 of 62
Secure repositories, builds, runtimes and testing tools
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: The build pipeline is part of the trust boundary.
Explore the anchors
Protect repositories dependencies and reviews.
Concept matching activity
Match this task or description to its concept:
Control identities tools and artifact integrity.
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
- Protect the build ecosystem
Concepts and mechanisms
A development ecosystem includes languages, libraries, editors, repositories, build systems, artifacts, deployment configuration and runtime. Compromise of build identities or dependencies can affect every release. Protect source integrity, approvals, secrets, artifact provenance and deployment authority. Reproducible or repeatable builds provide specific evidence but do not automatically prove absence of malicious logic.
Design, evidence and tradeoffs
Static testing examines code or artifacts without executing the target; dynamic testing observes the running application; software composition analysis evaluates included components; interactive approaches add runtime instrumentation. Each has limitations. Establish release gates, an authorized exception route and retesting. Keep pulled environment secrets out of source and artifacts. An automation account needs only the permissions and environments required for its job.
Protect the build ecosystem
Repositories, libraries, package sources, IDE extensions, build tools and runtimes can change the produced artifact. Protect branch and release permissions, pipeline identities, dependency updates, build provenance and artifact promotion. CI/CD automation shortens feedback but can also automate propagation of a compromised dependency. Audit meaningful changes and restrict secrets to the jobs that need them. Separate successful tests from provenance and approval evidence; each answers a different release question.
Worked example
A build can read production secrets unnecessarily, so the team restricts its identity and secret exposure rather than relying only on code scans.
Check your understanding
Why does a clean dependency scan not validate custom authorization logic?
Show explanation
Component exposure and the application’s own resource-permission behavior are different assurance questions.
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.