vLLM 0.30

Apply these rules to vLLM 0.30 after the Python baseline; they were checked against 0.30.0. Treat the inference engine, its model code, workers, and administrative interfaces as one trusted service; implement end-user and tenant policy before requests enter that service.

Runtime and serving boundary

• Lock vLLM to one exact release in the lock file and the image, and move to the newest release when a fix ships: vLLM puts out a regular minor release about every two weeks, does not promise long-term or parallel maintained minors in its release policy, and saves patch releases for new models and emergency fixes, so a fix usually arrives in the next minor. Read vLLM's GitHub security advisories page when you choose a release, not only your scanner's output: vLLM publishes its advisories there first, and some reach the databases that pip-audit and OSV-Scanner read only weeks later. Run it on a maintained Python version within its declared range, 3.10–3.14, and verify the selected accelerator wheel's narrower requirements. Match the CUDA distribution to the PyTorch build and published CUDA variant of the release you lock; the 0.30.0 CUDA wheels use PyTorch 2.13.0 and CUDA 13.0 by default, with separate 12.9 artifacts. Build against the intended stack when reusing a different PyTorch or accelerator build.
• Put the HTTP listener behind an authenticated TLS gateway that permits explicit route-and-method pairs and enforces tenant quotas. Bind --host to the intended private interface or use a protected --uds; prevent clients from connecting directly to the backend.