A public-health LLM stack remains pinned to an old vulnerable SDK. What supply-chain concern should the assessment raise?
Select an answer to reveal the explanation.
Short Explanation
Pinning forever to a known-bad SDK is stale-dependency risk—the stack is stuck in yesterday. You're not facing a Trojanized container image from a public mirror, spoofed model provenance, or a compromised build pipeline; you're facing an unpatched SDK pin.
Full Explanation
A public-health LLM stack that remains pinned to an old vulnerable SDK raises version-downgrade or stale-dependency risk in the municipal AI software stack. Stale or deliberately downgraded AI SDKs leave inference clients, guardrail libraries, connectors, or tool adapters exposed to known defects that attackers can exploit even when prompts and models look benign. Offensive and assurance reviews flag missing upgrade paths, frozen pins without compensating controls, absent vulnerability monitoring for AI-specific dependencies, and lack of SBOM coverage for the assistant runtime. A Trojanized container base image pulled from a public registry mirror, spoofed model provenance attestation tied to an external artifact repository, and a compromised build pipeline injecting extra code into municipal release artifacts do not remediate vulnerable libraries. On the exam, pinned vulnerable AI components map to supply-chain and stale-dependency concerns rather than facilities amenities. Caveat: blind auto-upgrades can break validated clinical workflows; pair timely patching with staged regression tests and an emergency expedite path for critical CVEs affecting resident-facing health assistants. Operational check: inventory AI SDK versions against current advisories, confirm a tracked upgrade ticket exists for any vulnerable pin, and verify the build pipeline fails or warns when known-bad versions are reintroduced.