A county continuous-integration portal similar to Jenkins is reachable from the internet with weak password-only auth. How should the tester prioritize it?
Select an answer to reveal the explanation.
Short Explanation
A CI box with a flimsy lock is the master key factory sitting on the sidewalk. Build systems often hold secrets, deploy rights, and code trust. Internet exposure plus weak auth jumps the priority queue.
Full Explanation
CI/CD admin portals with weak password-only authentication exposed to the internet are crown-jewel targets. A county continuous-integration system similar to Jenkins can often deploy code, hold secrets, and reach production networks—so weak internet auth is high-impact common-app exposure, not a cosmetic branding issue for municipal software delivery.
CI tools can absolutely affect production via pipelines and credentials. Sharing a TLS certificate with the main site is irrelevant to prioritization. A missing security.txt file is far lower impact than an exposed CI admin plane.
Exam caveat: treat build/deploy consoles like production admin entry points—MFA, network restriction, and patching. CPTS common-application ranking places CI/CD near the top when reachable.
Operational check: remove internet exposure or place behind SSO/VPN, enforce MFA and strong auth, audit credentials in the CI vault, and verify the county portal is no longer password-only from the public internet. CI secret scanning and least-privilege deploy credentials reduce blast radius even after the county portal’s network exposure is corrected. Internet-exposed CI is a county production risk because pipelines often hold deploy keys.