Developers began using unapproved cloud scanners that upload municipal source to third-party tenants. What should leadership do first for tooling governance?
Select an answer to reveal the explanation.
Short Explanation
Free scanners that vacuum city source into someone else's cloud are not a bargain. Leadership needs an approved toolbox and a clear ban on shadow tools that walk off with code. Governance beats "move fast and leak the repo."
Full Explanation
Tooling governance starts with an approved security tool set and an explicit prohibition on shadow scanners that exfiltrate municipal source to unmanaged third-party tenants. Free or convenient SaaS analyzers may upload code, secrets, and civic logic outside contractual and privacy boundaries. Leadership must define which SAST/SCA/secret-scanning products are authorized, how data is handled, and how exceptions are requested—then block or detect unapproved exfiltration paths.
Encouraging any free SaaS scanner regardless of data-handling terms maximizes supply-chain and confidentiality risk. Price-zero tools still process sensitive source; terms and residency matter for government data.
Storing copies of production PII inside every developer's laptop IDE expands breach impact and contradicts data-minimization; it is unrelated to fixing scanner governance and worsens the risk profile.
Disabling MFA on the code host to ease plugin installation trades authentication strength for convenience and increases account-takeover risk on the repository itself.
Exam caveat: CISSP emphasizes governance of third-party tools and data handling—not unrestricted adoption of free scanners. Operational check: publish an approved AppSec toolchain, route purchases through security review, monitor for anomalous uploads from developer endpoints, train staff on shadow-IT bans, and provide a fast path to evaluate new tools so teams are not forced into unofficial workarounds.