Internal shared libraries for the city’s cloud apps must stay in a controlled package repository, while carefully vetted open-source dependencies may come from public registries. What distinction should the platform team enforce?
Select an answer to reveal the explanation.
Short Explanation
Keep the city’s own libraries in a private package repo—like a locked supply closet. Public registries are fine for vetted open source, but don’t dump internal code out on the sidewalk. Governance on what is public versus private saves embarrassing leaks.
Full Explanation
Internal shared libraries for the city's cloud apps must stay in a controlled package repository, while carefully vetted open-source dependencies may come from public registries; the platform team should store proprietary internal libraries in private package repositories and consume public open-source packages only through governed public or proxied registries. That distinction protects intellectual property and supply-chain control for municipal code. Publishing every internal library to anonymous public registries by default for convenience risks leaking civic proprietary logic. Forbidding all package repositories and copying binaries only over unmanaged email destroys provenance and automation. Treating public container registries as the only place to store citizen private data backups confuses package hosting with sensitive data storage. Exam caveat: governance often includes allowlists, vulnerability scanning, and mirroring of approved public packages rather than uncontrolled direct Internet pulls from build agents. Operational check: publish an internal library only to the private feed, configure pipelines to authenticate to that feed, route public dependencies through the approved proxy/mirror, block anonymous publishes of internal packages, and document the civic package-source policy for developers.