Module B14 — MLSecOps: The ML Security Lifecycle · Pillar 4 — Frameworks & Governance

MLSecOps — the ML security lifecycle, named and mapped

The term appears in over thirty files across the course corpus, always as a forward reference, never as a taught subject. This module teaches it. Six stages — data, supply chain, training, deployment, inference, incident response — each mapping to content you have already learned. The value is the lifecycle, not the content.

minutes

artifacts

lifecycle stages

MLSecOps is not new content — it is the connective discipline that ties together C1's harness engineering, C2B's AI security, and C3's fine-tuning into a single security lifecycle. This module names the discipline and maps the existing content into it. You have already learned every stage. What you have not done is see them as one lifecycle, with a toolchain and an operating cadence that runs from data, through training, through deployment, through inference, through incident response.

Key Claims

Load-Bearing Claims

MLSecOps is not new content — it is the connective discipline. Every stage maps to content already taught: data security to C3 Pillar 1 + C2B B3; model supply chain to C2B B4/SDD-B07 + B13; training security to C3 Pillars 2–5; deployment security to C2B B7 + C1 Module 5; inference monitoring to C2B B8 + C1 Module 10; incident response to C2B Capstone 2. What MLSecOps adds is the naming, the ordering, the gates between stages, the toolchain, and the operating cadence — the connective tissue that turns pieces into a discipline.

MLSecOps extends DevSecOps: five primitives transfer, five are genuinely new. The transferring primitives (SBOM, CI/CD gates, signed artifacts, secrets management, least privilege) apply because the underlying problem is the same — an artifact is produced, transported, verified, deployed, operated. The new primitives (model scanning, adversarial robustness, drift detection, prompt-injection monitoring, representation-layer analysis) have no DevSecOps analogue because they arise from properties of ML that software does not have. The anti-pattern 'we have a CI/CD pipeline, so we are doing MLSecOps' is the team that does the transferring primitives and misses the five new ones.

The deployment gate is the single most important MLSecOps practice. A model does not reach production until four composed checks pass, with evidence recorded in the model SBOM: data security (corpus hash matches manifest, poisoning detection below threshold), model supply chain (ModelScan passed, base SBOM verified, publisher signature valid), training security (red-team eval above threshold, no critical adversarial perturbations), deployment security (harness checklist complete and passing). Production is a privilege earned by evidence, not a default.

No single tool covers the lifecycle — integrate by stage, via shared evidence. ModelScan covers model-supply-chain scanning; ProtectAI's broader suite covers training, deployment, and monitoring; HiddenLayer is strongest at inference monitoring and training-poisoning detection; Robust Intelligence distinguishes itself with continuous validation. Each produces evidence (scan results, eval scores, monitoring alerts) that the model SBOM carries forward to the next stage's gate. The SBOM is the integration point, not any single vendor's stack.

After This Module

Name the six stages of the MLSecOps lifecycle — data security, model supply chain, training security, deployment security, inference monitoring, incident response — and describe the security concern, the failure mode, and the control for each.

Map every stage of the MLSecOps lifecycle to existing course content: data security → C3 Pillar 1 + C2B B3; model supply chain → C2B B4 / SDD-B07 + B13 representation attacks; training security → C3 Pillars 2–5; deployment security → C2B B7 + C1 Module 5; inference monitoring → C2B B8 + C1 Module 10; incident response → C2B Capstone 2.

Articulate how MLSecOps extends DevSecOps for AI — the primitives that transfer (SBOM, CI/CD gates, signed artifacts, secrets management), the primitives that are new (model scanning, adversarial robustness, drift detection, prompt-injection monitoring), and why naively applying DevSecOps to ML produces gaps.

Evaluate the MLSecOps tool landscape — ModelScan (ProtectAI), the broader ProtectAI suite, HiddenLayer, Robust Intelligence — by the lifecycle stage each covers and the threat each addresses, and design an integrated toolchain rather than a collection of point products.

Build a model scanning pipeline that takes a .safetensors file, extracts its tensor metadata, and checks it against known backdoor patterns — the canonical deployment gate that prevents a poisoned or trojaned model from reaching production.

Artifacts

Teaching Document

~3,800 words; 3 sub-sections — the six stages (data, supply chain, training, deployment, inference, incident response, each with concern/failure/control/maps-to); how MLSecOps extends DevSecOps (five transferring + five new primitives); the toolchain and operating cadence (ModelScan, ProtectAI, HiddenLayer, Robust Intelligence; the deployment gate; the lab)

READ

Diagrams

5 Mermaid diagrams — the six-stage lifecycle with course mapping, MLSecOps extends DevSecOps (transfer vs new), the deployment gate (four composed checks), the tool landscape (vendors by stage), the incident-response feedback loop

READ

Slide Deck

12 slides — reveal.js, dark theme, design-system teal; covers the thesis (connective discipline), the six stages with mapping, stages 1+2, stages 3+4, stages 5+6, how MLSecOps extends DevSecOps, the deployment gate, the tool landscape, anti-patterns, the lab

READ

Teaching Script

Verbatim teaching transcript with [SLIDE N] cues, ~3,000 words spoken at ~140 wpm across 12 slide cues