Artificial Intelligence Vulnerability Management: A Bash‑First Playbook for Linux

AI systems are shipping faster than ever. Models, vector DBs, CUDA drivers, Python deps, and containers all pile up into a tangled supply chain. One weak link—a malicious model file, an unpatched CVE in your image, or a leaky prompt handler—and your AI stack can become an attacker’s stack.

This article gives you a practical, Bash-centric approach to AI Vulnerability Management on Linux. You’ll get a clear rationale for why this matters, plus 3–5 actionable steps, with commands you can paste into a terminal. Where tools are installed, we include apt, dnf, and zypper instructions.

---

Why AI vulnerability management is different (and urgent)

• Fast-moving dependencies: Frameworks like PyTorch, TensorRT, and tokenizers update often; critical CVEs appear frequently.

• New artifact types: Models, embeddings, and dataset snapshots are opaque binaries; traditional app scanners may miss them.

• Expanded attack surface: Prompt injection, data exfiltration from tools, and model/plugin supply chain risk.

• Heterogeneous runtime: CPU/GPU combinations, containerization, and mixed privilege boundaries.

Bottom line: treat your AI stack like a production system with a dynamic software supply chain—because it is.

---

0) Quick prerequisites

You’ll use a few standard tools. Install them once:

• curl + jq

  • apt:

  sudo apt-get update && sudo apt-get install -y curl jq
  

  • dnf:

  sudo dnf install -y curl jq
  

  • zypper:

  sudo zypper install -y curl jq
  

• Python + pip/venv (for Python dependency auditing)

  • apt:

  sudo apt-get update && sudo apt-get install -y python3 python3-venv python3-pip
  

  • dnf:

  sudo dnf install -y python3 python3-pip python3-virtualenv
  

  • zypper:

  sudo zypper install -y python3 python3-pip python3-virtualenv
  

---

1) Inventory your AI assets and generate SBOMs

You can’t secure what you don’t know you have. Start by building an inventory and SBOM (Software Bill of Materials) for:

• Your repository (code + config + model files)

• Your container images (training and inference)

• Any system images that ship models or tooling

We’ll use Trivy for SBOM and scanning.

Install Trivy

• apt (Ubuntu/Debian):

  sudo apt-get update && sudo apt-get install -y wget gnupg lsb-release
  wget -qO - https://aquasecurity.github.io/trivy-repo/deb/public.key | gpg --dearmor | sudo tee /usr/share/keyrings/trivy.gpg >/dev/null
  echo "deb [signed-by=/usr/share/keyrings/trivy.gpg] https://aquasecurity.github.io/trivy-repo/deb $(lsb_release -sc) main" | sudo tee /etc/apt/sources.list.d/trivy.list
  sudo apt-get update && sudo apt-get install -y trivy
  

• dnf (Fedora/RHEL/CentOS; uses $releasever):

  sudo rpm --import https://aquasecurity.github.io/trivy-repo/rpm/public.key
  sudo bash -c 'cat >/etc/yum.repos.d/trivy.repo << "EOF"
  [trivy]
  name=Trivy repository
  baseurl=https://aquasecurity.github.io/trivy-repo/rpm/releases/$releasever/$basearch/
  enabled=1
  gpgcheck=1
  gpgkey=https://aquasecurity.github.io/trivy-repo/rpm/public.key
  EOF'
  sudo dnf makecache && sudo dnf install -y trivy
  

• zypper (openSUSE/SLE; uses $releasever):

  sudo rpm --import https://aquasecurity.github.io/trivy-repo/rpm/public.key
  sudo bash -c 'cat >/etc/zypp/repos.d/trivy.repo << "EOF"
  [trivy]
  name=Trivy Repository
  enabled=1
  autorefresh=1
  baseurl=https://aquasecurity.github.io/trivy-repo/rpm/releases/$releasever/$basearch/
  type=rpm-md
  gpgcheck=1
  gpgkey=https://aquasecurity.github.io/trivy-repo/rpm/public.key
  EOF'
  sudo zypper refresh && sudo zypper install -y trivy
  

Create SBOMs (CycloneDX or SPDX)

• Repository SBOM:

  trivy fs --format cyclonedx -o sbom.cdx.json .
  

• Container image SBOM:

  IMAGE="pytorch/pytorch:2.3.0-cuda11.8-cudnn8-runtime"
  trivy image --format cyclonedx -o image.cdx.json "$IMAGE"
  

• Model directory SBOM (treat models like third-party binaries):

  trivy fs --format cyclonedx -o models.cdx.json /opt/models
  

Tip: Commit SBOMs or publish them with your release artifacts to track changes across versions.

---

2) Continuously scan Python dependencies and containers

Most AI stacks are Python-heavy. Combine Python dep audits with image scanning.

Python dependencies (pip-audit)

Install pip-audit (from the Python Packaging Authority):

python3 -m pip install --user pip-audit

Audit a project (inside a virtual environment is best):

python3 -m venv .venv
. .venv/bin/activate
pip install -r requirements.txt
pip-audit -r requirements.txt

To make CI fail on known vulns, keep the non-zero exit code:

pip-audit -r requirements.txt || exit 1

Generate a JSON report:

pip-audit -r requirements.txt -f json -o pip-audit.json

Container images and local filesystem (Trivy)

• Scan an image for HIGH/CRITICAL CVEs:

trivy image --severity HIGH,CRITICAL --ignore-unfixed "$IMAGE"

• Scan your working directory (code, scripts, IaC, and secrets):

trivy fs --scanners vuln,misconfig,secret --severity HIGH,CRITICAL .

Automate with cron

Create a minimal weekly job that drops reports in reports/ with timestamps:

mkdir -p reports
cat > ai-vuln-scan.sh << 'EOF'
#!/usr/bin/env bash
set -euo pipefail
TS="$(date -u +%Y%m%dT%H%M%SZ)"
mkdir -p reports

# Python deps
if [ -f requirements.txt ]; then
  python3 -m pip install --user pip-audit >/dev/null 2>&1 || true
  pip-audit -r requirements.txt -f json -o "reports/pip-audit-$TS.json" || true
fi

# Filesystem and image scans
trivy fs --scanners vuln,misconfig,secret --format json -o "reports/trivy-fs-$TS.json" .
if command -v jq >/dev/null 2>&1; then
  jq '.Results[].Vulnerabilities? // [] | length' "reports/trivy-fs-$TS.json" | paste -sd+ - | bc
fi

IMAGE="${1:-}"
if [ -n "$IMAGE" ]; then
  trivy image --format json -o "reports/trivy-image-$TS.json" "$IMAGE" || true
fi
EOF
chmod +x ai-vuln-scan.sh

Add to crontab (weekly, 3:17am):

( crontab -l 2>/dev/null; echo "17 3 * * 1 cd /path/to/repo && ./ai-vuln-scan.sh pytorch/pytorch:2.3.0-cuda11.8-cudnn8-runtime" ) | crontab -

---

3) Harden and sandbox AI runtimes

Treat the model server like any high-risk service. Run it least-privileged with tight resource and network controls.

We’ll use Podman (rootless by default on many distros).

Install Podman

• apt:

  sudo apt-get update && sudo apt-get install -y podman
  

• dnf:

  sudo dnf install -y podman
  

• zypper:

  sudo zypper install -y podman
  

Run an inference container with strong defaults

MODEL_DIR=/opt/models
IMAGE=ghcr.io/example/ai-inference:latest

podman run --rm --name ai-svc \
  --user 1001:1001 \
  --read-only \
  -v "$MODEL_DIR":/models:ro \
  --cap-drop ALL \
  --security-opt no-new-privileges \
  --pids-limit 256 \
  --memory 4g --memory-swap 4g \
  --cpus 2 \
  --network none \
  -e TRANSFORMERS_OFFLINE=1 \
  "$IMAGE" \
  python -m serve --model-path /models

Notes:

• --read-only and :ro prevent tampering with the filesystem and models.

• --cap-drop ALL and --security-opt no-new-privileges reduce kernel attack surface.

• --network none blocks egress by default (great against prompt injection‑led exfiltration).

• Map a non-root user and set resource limits to constrain blast radius.

If you must allow egress (e.g., telemetry), prefer a sidecar proxy with an explicit allowlist rather than full internet.

---

4) Control data flow and prompts at the boundary

Even well-hardened services can leak via tools or misconfigured plugins. Enforce egress restrictions and sanitize runtime env.

Host-level egress controls

• Ubuntu/Debian (UFW):

  sudo apt-get update && sudo apt-get install -y ufw
  sudo ufw enable
  # Default deny inbound
  sudo ufw default deny incoming
  # Optional: restrict outbound (be careful—this is host-wide)
  # sudo ufw default deny outgoing
  # Allow only specific egress as needed (example DNS and a single API)
  sudo ufw allow out 53
  sudo ufw allow out to 203.0.113.10 port 443 proto tcp
  sudo ufw status verbose
  

• Fedora/openSUSE (firewalld):

  # Install and start firewalld
  sudo dnf install -y firewalld || sudo zypper install -y firewalld
  sudo systemctl enable --now firewalld
  
  # Create a locked-down zone for AI service
  sudo firewall-cmd --permanent --new-zone=ai
  sudo firewall-cmd --permanent --zone=ai --set-target=DROP
  # Whitelist a specific egress destination (example API)
  sudo firewall-cmd --permanent --zone=ai --add-rich-rule='rule family="ipv4" destination address="203.0.113.10" port protocol="tcp" port="443" accept'
  sudo firewall-cmd --reload
  
  # Run your container attached to the ai zone (Podman)
  podman network create --driver=bridge --subnet 10.10.0.0/24 --gateway 10.10.0.1 ai-net
  sudo firewall-cmd --permanent --zone=ai --add-interface=podman-ai-net || true
  

Tip: When possible, keep --network none and mount any needed data locally. Outbound-only allowlists are your friend.

Sanitize environment and inputs

Strip ambient environment variables so secrets don’t leak into the model process:

env -i PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin TRANSFORMERS_OFFLINE=1 \
  python -m serve --model-path /models

Add simple input size and character filters in your gateway before requests hit the model, and log/alert on obvious prompt injection patterns. Even basic controls reduce risk.

---

5) Verify provenance: pin and verify your models

Treat model files like any third‑party binary. Pin and verify before loading.

• Create and store checksums (committed to your repo or release metadata):

  cd /opt/models
  sha256sum model.bin tokenizer.json > SHA256SUMS
  

• Verify at startup:

  cd /opt/models
  sha256sum -c SHA256SUMS
  

• Pin exact versions in requirements and container tags:

  # requirements.txt
  transformers==4.42.4
  tokenizers==0.15.2
  
  # Container image tag (avoid :latest)
  IMAGE="pytorch/pytorch:2.3.0-cuda11.8-cudnn8-runtime"
  

This guards against model tampering and accidental version drift.

---

Real-world pattern to emulate

• Maintain SBOMs alongside code and images.

• Gate merges on pip-audit and trivy results.

• Run inference containers rootless, read-only, with no network by default.

• Explicitly verify model checksums before load.

• Add an outbound allowlist only when needed.

This combo materially reduces supply chain and runtime risk without slowing you down.

---

Conclusion and next steps (CTA)

AI vulnerability management is not a one-off scan—it’s a workflow. Start today:

1) Generate SBOMs with Trivy and commit them.
2) Add pip-audit and trivy scans to CI; fail on HIGH/CRITICAL.
3) Run your inference service with Podman using the hardening flags above.
4) Lock down egress and verify model checksums on every deploy.

Turn the snippets in this post into scripts in a security/ directory and wire them into CI/CD. If you want a ready-to-use baseline, clone your repo’s infra folder, drop in the cron job and Podman run template, and iterate from there.

If you found this useful, subscribe and watch for a follow-up where we’ll wire these checks into GitHub Actions and GitLab CI, and add runtime policy with SELinux/AppArmor profiles.