Why should dependency vulnerabilities be scanned in an ML delivery process?

Dependency vulnerability scanning checks the software libraries and packages used by an ML system against databases of known security flaws.

An ML model can predict accurately while the API, training worker, or container running it contains a vulnerable package. That makes scanning part of releasing and maintaining a safe ML service, not just an optional security audit.

A beginner-friendly example

Imagine a food-delivery company deploying an API that predicts delivery times. Its service uses Python, a web framework, numerical libraries, and a container base image.

Before a release, an automated scanner reports that one installed package version has a published security advisory. This is a hypothetical finding, not a claim about a specific library.

The team checks whether the vulnerable functionality can actually be reached in its deployment, whether a patched version exists, and what the business impact could be. If an upgrade is appropriate, it updates the dependency, reruns model-serving tests, rebuilds the image, and scans again.

Without scanning, the model's accuracy tests might all pass while the vulnerable software remains deployed.

What should an ML team scan?

1. Direct Python dependencies: Libraries explicitly used by training, batch scoring, and inference code.
2. Transitive dependencies: Packages installed because other packages require them; these may be overlooked by developers.
3. Container and operating-system packages: System libraries and utilities inherited from the base image, not only what appears in requirements.txt.
4. Deployed artifacts: The actual container image or environment released to production, because its contents can differ from the source dependency files.

For GPU workloads, also consider the security and compatibility of relevant accelerator runtimes and drivers. A Python-only scan cannot evaluate all host or container components.

A simple scanning example

A team can use pip-audit to check the dependencies in a Python requirements file:

BASH
pip-audit -r requirements.txt

After building a prediction-service image, it can use Trivy to check detected language packages and supported operating-system packages:

BASH
trivy image delivery-time-api:1.0

These commands assume the tools are installed, the requirements file is available, and the image can be accessed. They report known vulnerabilities according to the tool's data sources and detection capabilities; a clean report is not proof that the service is secure.

Where should scanning fit in delivery?

• On pull requests: Detect newly introduced vulnerable dependencies before changes merge.
• During the build: Scan the resolved dependencies and built container image before release.
• At release approval: Review findings against the team's documented risk policy; block a release when an unacceptable risk remains.
• After deployment: Rescan or continuously monitor released artifacts. A vulnerability may be disclosed after an unchanged image goes live.

A practical pipeline is:

Dependency change → Build → Scan → Assess findings → Fix or approve a time-limited exception → Test → Release → Rescan

The scan should produce a visible report and a clear person or team responsible for unresolved findings.

How should vulnerabilities be prioritized?

Not every alert has the same operational risk. Consider:

• Severity: How serious is the reported flaw according to relevant advisories?
• Exposure: Can an attacker reach the affected functionality in this particular training job or prediction service?
• Evidence of exploitation: Is the vulnerability known to be exploited, for example through CISA's Known Exploited Vulnerabilities catalog?
• Available remediation: Is there a patched release, a replacement package, or a compensating control?
• Business impact: Is this a public prediction API, an internal isolated batch job, or a component with access to sensitive data?

For example, a remotely exploitable flaw in an internet-facing inference API generally deserves more urgent attention than an unreachable issue in an isolated development-only tool. Document decisions; do not silently ignore alerts or automatically upgrade every ML library without compatibility testing.

What does scanning *not* replace?

• An SBOM inventories components. Scanning identifies known security advisories affecting detected components. They complement one another but are not the same process.
• Dependency pins and lockfiles preserve chosen versions; they do not guarantee those versions remain safe forever.
• Application and model security testing still matter. A dependency scanner does not necessarily detect custom code bugs, malicious model files, exposed credentials, or weaknesses in ML-specific workflows.

In short: Scan dependencies before release and throughout their deployed lifetime. Investigate findings in context, update safely, and verify fixes without breaking model behavior.