Setting a Scanning Cadence for Your Model-Serving Stack

• Inference server software (your model-serving framework), which sees less scrutiny than app frameworks because it's newer and less familiar to most security tooling.
• Container base images, rebuilt and rescanned on a schedule, not left running because the model still works.
• GPU driver and CUDA-adjacent libraries, often overlooked because they feel like infrastructure rather than application surface, despite running with significant privileges.
• Any open-source serving framework dependencies, pinned versions that can sit unpatched for months if nobody's specifically watching that repository's security advisories.

A scan that only covers your application code misses all four of these.

CISA's federal guidance requires critical, internet-facing vulnerabilities to be remediated within 15 days, and high-severity ones within 30¹. That's a reasonable floor to adopt even outside government work, and it should apply specifically to your inference layer, not just your general application stack.

Where a known exploited vulnerability is involved, tighten the window further; federal guidance treats those as urgent enough to warrant a much shorter turnaround than a routine critical finding. If your inference gateway is internet-facing at all, that's the standard to hold it to.

CrowdStrike focuses on endpoint and runtime threat detection, useful for catching active exploitation on the machines running your inference workloads. Tenable focuses on scanning and inventory, useful for finding vulnerabilities before they're exploited in the first place.

Neither tool understands model-serving specifics like tool-calling schemas or prompt injection risk out of the box; they cover the infrastructure layer, GPU hosts, container images, network exposure, which is necessary but not sufficient. Pair them with the model-specific review covered elsewhere in your security process, not as a replacement for it, and revisit that pairing whenever you add a new provider or serving framework.

Say a critical CVE is published for a popular open-source inference server, and you're running an affected version. A scanning tool that has that server's package indexed flags it within hours of the advisory; one that only scans your application dependencies never sees it at all, because the serving framework sits at the infrastructure layer.

Confirm your scanning coverage explicitly includes whatever serving framework you run, by name, rather than assuming a general dependency scan already covers it, and check that assumption again after any infrastructure change.

Ask specifically whether your asset inventory, the list every scanning tool works from, actually includes GPU hosts and the inference server processes running on them, not just the general compute fleet. Infrastructure teams sometimes provision GPU nodes through a separate process from standard compute, which means they can quietly sit outside the inventory your scanner actually checks against.

Confirm this directly rather than assuming it: pull your scanner's asset list and cross-reference it against your actual GPU fleet. A gap here means every subsequent scan looks clean while missing an entire category of machine, and it tends to stay missed until someone happens to check by hand.

A simple cadence to start from is to scan container images on every build, rescan running images on a regular schedule because new advisories appear after a build ships, and review GPU driver and serving framework advisories on a fixed calendar. Assign each layer a named owner, since scanning that belongs to everyone tends to be done by no one. For example, the platform team might own images and drivers while the ML team owns the serving framework version. Record each scan date so you can show a pattern of practice, not a single snapshot, when a customer asks.

• Scanning application dependencies thoroughly while never confirming the inference server itself is in scope.
• Treating a clean scan on the day of a security review as proof of an ongoing practice, rather than a snapshot.
• Patching based on severity score alone, without checking whether the vulnerable component is actually internet-facing, which should change your priority order.