AppSec discovers a poisoned dependency in a feature-engineering package used across city ML pipelines. What pipeline response best addresses the risk?
Select an answer to reveal the explanation.
Short Explanation
A bad feature package in every city pipeline is contaminated flour in the bakery. Block it, clean credentials if needed, and rebuild clean. Pinning the bad version, killing scanners, and Slack-only hashes do not remediate.
Full Explanation
When AppSec discovers a poisoned dependency in a feature-engineering package used across city ML pipelines, the best response is to block the package, rotate affected credentials, and rebuild from a clean bill of materials. A poisoned package may have already executed install-time or import-time code, harvested tokens, or altered feature transforms that feed multiple civic models. Blocking stops further installs; credential rotation limits the window if secrets were stolen; rebuilding from a verified SBOM/BOM restores confidence that training and serving artifacts are not still carrying the compromised dependency.
Pinning the poisoned version citywide so builds stay reproducible fails because reproducibility of a known-bad artifact preserves the compromise. Disabling dependency scanning to avoid false positives fails because it removes detection for the next incident. Embedding the package hash only in Slack messages fails because informal chat is not an enforceable allow/deny control in build systems.
Exam caveat: after confirmed poison, “pin for reproducibility” is a trap; municipal response prioritizes containment, secret hygiene, and clean rebuild—not freezing malware in place.
Operational check: add the package/version to the deny list in the city’s dependency firewall; revoke and rotate CI and training-account credentials used where the package ran; regenerate SBOM for affected pipelines; rebuild and re-sign model/feature artifacts before returning them to production paths.