School-district CI pulls packages through an external open-source cache. What control should guard that access?
Select an answer to reveal the explanation.
Short Explanation
Even a friendly package cache needs a badge check—AuthN/Z keeps the district's pull path accountable. Wide-open anonymous publish/pull is how supply-chain messes start.
Full Explanation
When school-district CI pulls packages through an external open-source cache, authenticated access controls (AuthN/Z) should guard that access. Even caching public open-source components, the district’s pull (and especially any publish) path must be accountable: authenticated identity, authorization to the cache, and preferably audit logs. AuthN/Z reduces anonymous abuse, enforces who may upload, and supports supply-chain governance for educational systems.
Disabling all authentication so any anonymous host may pull and publish fails by concept: open publish paths invite malware substitution and untracked consumption. Hard-coding a community wiki password into every student Chromebook fails secret distribution and is unrelated to proper CI-to-cache AuthN/Z. Skipping dependency fetches and inventing library stubs by hand fails build integrity—you no longer test or ship real dependencies.
Exam caveat: some read-only public registries are anonymous by nature; the stem’s “guard that access” for a district cache used by CI emphasizes controlled AuthN/Z on the district’s cache/proxy, especially where publish or internal packages exist. Do not disable auth for convenience.
Operational check: require CI service accounts to authenticate to the package cache, separate read and publish roles, monitor anonymous access attempts, rotate cache credentials, and ensure school pipelines fail closed when AuthN/Z to the cache is misconfigured rather than falling back to wide-open anonymous mode.