Security scans find a known CVE in the city’s self-hosted LLM inference gateway software. What infrastructure practice is indicated?
Select an answer to reveal the explanation.
Short Explanation
You can think of a known gateway CVE as a cracked lock on the city’s AI door: patch the serving stack promptly. Ignoring serving flaws, pinning forever to a vulnerable build, or silencing scanners leaves that crack open.
Full Explanation
A known CVE in the city’s self-hosted LLM inference gateway is a serving-tier vulnerability on the path residents and clerks use. The indicated practice is timely patch management for GenAI serving and gateway components: inventory versions, assess exploitability against municipal exposure, patch or mitigate, and verify closure. Training clusters are not the only GenAI surfaces that need vulnerability management; gateways and inference servers are high-value civic infrastructure that may be enterprise- or internet-facing. Ignoring serving CVEs because only training clusters need patches mis-scopes the threat and leaves the resident-facing path exposed. Pinning forever to a vulnerable build for reproducibility theater freezes known risk; reproducibility should rely on approved, patched baselines with recorded versions. Disabling scanners so dashboards stay green for council reports hides risk from governance rather than reducing it. Exam caveat: emergency measures such as WAF virtual patches or temporary exposure reduction may buy time, but do not replace applying vendor or upstream fixes to the gateway itself. Practical check: confirm the production gateway version, map the CVE to fixed releases, schedule a maintenance window, re-scan after patching, and retain evidence that the municipal GenAI serving finding is closed.