# Teaching Script — Module B14: MLSecOps — The ML Security Lifecycle

**Course**: 2B — Securing & Attacking Harnesses and LLMs
**Module**: B14 — MLSecOps: The ML Security Lifecycle
**Duration**: ~40 minutes (spoken at ~140 wpm)
**Format**: Verbatim transcript with `[SLIDE N]` cues. Read aloud or use as speaker notes.

---

[SLIDE 1 — Title]

Welcome to module B-fourteen, MLSecOps — the ML security lifecycle. This module is different from the ones before it. It does not teach a new attack, a new defense, or a new technique. It names a discipline — MLSecOps — and maps the content you have already learned into a single lifecycle. The term appears in over thirty files across this course's corpus, always as a forward reference, never as a taught subject. This module teaches it.

The load-bearing insight is on the title slide: MLSecOps is not new content. It is the connective discipline that ties together C-one's harness engineering, C-two-B's AI security, and C-three's fine-tuning into a single security lifecycle. 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. That is what this module provides.

[SLIDE 2 — The thesis: MLSecOps is the connective discipline]

Here is the thesis. The course has taught AI security in pieces. Course one taught harness engineering — the deterministic wrapper around a probabilistic model. Course two-B taught the attacks on that harness — prompt injection, memory poisoning, tool abuse, supply-chain compromise, the OWASP Agentic Top Ten. Course three teaches fine-tuning, with the data, training, and evaluation disciplines that produce a model worth deploying.

The pieces are complete. What is missing is the lifecycle view — the discipline that names the stages, defines the gates between them, specifies the toolchain, and runs the cadence. On the left, what the course taught in pieces. On the right, what MLSecOps adds: the lifecycle view. The naming, the ordering, the gates, the toolchain, the cadence. The connective tissue that turns pieces into a discipline.

The value is the lifecycle, not the content. A team that learned C-one, C-two-B, and C-three in isolation knows the controls. A team that learned MLSecOps knows when to apply each control, what gate it belongs in, and what tool implements it. That is the difference this module makes.

[SLIDE 3 — The six stages, mapped to existing content]

The six stages, in one orientation slide. Read across: data security, model supply chain, training security, deployment security, inference monitoring, incident response. For each, the security concern and the course module that teaches it.

Stage one, data security. The concern is data integrity, provenance, and representativeness. The control is chain-of-custody, dataset signing, and poisoning detection. Maps to C-three Pillar one and C-two-B B-three.

Stage two, model supply chain. The concern is that the base model you downloaded is a dependency with supply-chain risks. The control is the model SBOM, ModelScan, registry verification, and hash matching. Maps to C-two-B B-four and SDD-B-zero-seven, plus B-thirteen representation attacks.

Stage three, training security. The concern is training-run integrity and adversarial robustness. The control is access-controlled infrastructure, adversarial training, and red-team evaluation. Maps to C-three Pillars two through five.

Stage four, deployment security. The concern is the deployed system — the model plus its harness — is secure. The control is the C-one five-layer harness and the C-two-B defenses, deployed as a gate. Maps to C-two-B B-seven and C-one Module five.

Stage five, inference monitoring. The concern is observing the model's behavior in production and detecting attacks, drift, and failures. The control is the observability substrate, anomaly detection, injection detection, and drift detection. Maps to C-two-B B-eight and C-one Module ten.

Stage six, incident response. The concern is detecting, containing, investigating, and remediating incidents — and feeding the lessons back into the earlier stages. Maps to C-two-B Capstone two.

Every stage maps to content already taught. MLSecOps adds the naming, the ordering, and the gates.

[SLIDE 4 — Stage 1 and 2: data security and model supply chain]

Zoom in on the first two stages. Data security. The failure mode is data poisoning — the attacker injects crafted examples that produce a backdoor or a bias. The hardest variant is the clean-label attack, where every injected example is correctly labeled, so the poisoning is invisible to label inspection. The structural variant is the data-supply-chain attack: the dataset is sourced from a third party — Common Crawl, a Hugging Face dataset, a purchased corpus — and the third party is compromised. The control is provenance, chain-of-custody, dataset signing, and statistical poisoning detection.

Model supply chain. The failure mode is the trojaned base model — a model that behaves normally on standard inputs but produces attacker-chosen outputs when a trigger appears. The typosquatted model — a name that closely resembles a legitimate model's, downloaded by a developer who mistyped. The evil-twin model with a valid signature, because the signature verifies the publisher, not the benignity — the same A-S-I-zero-eight pattern from SDD-B-zero-one, now at the model layer. The representation-level backdoor, encoded in the model's internal geometry, invisible to any input-layer inspection. The control is the model SBOM, ModelScan, registry verification, and hash matching. The model is a dependency — treat it like one.

The connection to SDD-B-zero-one's supply-chain row is worth restating. The signed-but-malicious anti-pattern applies at the model layer exactly as it applied at the tool layer. A signature verifies the publisher's identity, not the package's benignity, whether the package is a Python library, an M-C-P tool, or a base model. The model SBOM from SDD-B-zero-seven generalizes: a software SBOM lists libraries; an agent SBOM lists tools and models; a model SBOM lists base models, datasets, and training runs. The primitive is the same.

[SLIDE 5 — Stage 3 and 4: training and deployment security]

Stage three, training security. Two concerns. First, training-run integrity — no unauthorized modification of the training run. An attacker with access to the training infrastructure can modify the data, the hyperparameters, or the objective function, producing a model that serves the attacker's intent. The control is access-controlled infrastructure, hashed data verified before the run, version-controlled hyperparameters, and reproducibility from recorded inputs. Second, adversarial robustness — the model must resist the threats it will face in deployment. The control is adversarial training — the corpus includes adversarial examples — and red-team evaluation before deployment. A model that exits training without passing the red-team evaluation does not proceed to deployment.

Stage four, deployment security. The failure mode is the un-harnessed model — a model served without input validation, tool contracts, sandbox, or output handling, directly exposed to user input. This is the failure mode the entire C-one harness-engineering curriculum exists to prevent. The control is the five-layer harness from C-one — input validation, tool contracts, sandbox execution, output handling, observability — plus the C-two-B defenses. Deployment is a gate, not an event. The model does not reach production until it has passed the harness checklist, the red-team evaluation, and the model scan. We will return to the deployment gate in slide eight.

[SLIDE 6 — Stage 5 and 6: inference monitoring and incident response]

Stage five, inference monitoring. The load-bearing claim: no model is safe at rest; safety is a property of the running system. The threats are the deployed attacks — prompt injection, goal hijack, tool abuse — now observed live rather than prevented upfront. Drift — the input distribution shifts away from the training distribution, and behavior degrades. The slow compromise — an attacker probes over weeks, building toward a chain. The silent failure — plausible-but-wrong outputs that no monitor flags because they are structurally valid. The control is the observability substrate from B-eight and C-one Module ten: every inference logged, every tool call recorded, every output scored. Anomaly detection, injection detection, drift detection.

Stage six, incident response. The failure modes are the undetected incident, the slow-contained incident, the repeated incident, and the un-attributed incident. The control is runbooks per incident class — for prompt-injection breach, data exfiltration, supply-chain compromise, drift beyond thresholds — each with a containment procedure, a rollback path, and a communication plan. The Capstone two engagement is the rehearsal: the red team plays the attacker, the blue team plays the responder, and the engagement is a dry run of the incident-response procedure. And the feedback loop — every incident is attributed to the stage where the control failed, and the fix is applied to that stage's gate. The feedback loop is what makes MLSecOps a lifecycle, not a checklist. Without it, the same attack succeeds again next quarter.

[SLIDE 7 — How MLSecOps extends DevSecOps]

Now the framing that prevents the most common anti-pattern. MLSecOps is not a wholesale invention. The security-engineering primitives that DevSecOps developed over twenty years apply directly to the ML lifecycle. On the left, what transfers: the SBOM — software SBOM becomes model SBOM. CI/CD gates — code gates become model gates. Signed artifacts — image signatures become model and dataset signatures, with dot-safetensors as the format. Secrets management, least privilege. These transfer because the underlying problem is the same: an artifact is produced, transported, verified, deployed, and operated.

On the right, what is new. Five concerns have no DevSecOps analogue because they arise from properties of ML that software does not have. Model scanning — a binary scanner does not understand model files; a backdoor can be encoded in the statistical structure of millions of floating-point weights. Adversarial robustness — a model has a continuous robustness surface with no clean boundary between safe and unsafe inputs. Drift detection — a model's behavior depends on its inputs, and inputs drift over time. Prompt-injection monitoring — the LLM-specific attack surface. Representation-layer analysis — the model's internal geometry as a security surface. None of these have a software analogue.

The anti-pattern is the team that says "we have a CI/CD pipeline, so we are doing MLSecOps." They are doing the part that transfers. They are not doing the part that is new. The model deploys without a scan, without robustness eval, without drift detection, without injection monitoring, without representation analysis. The cure is not to abandon DevSecOps — the transferring primitives are necessary. The cure is to extend it: take the DevSecOps pipeline as the substrate, add the five ML-specific gates on top.

[SLIDE 8 — The deployment gate: four composed checks]

The single most important MLSecOps practice. The deployment gate. A model does not reach production until four checks have passed, and the evidence is recorded in the model SBOM. Check one, data security: the corpus hash matches the signed manifest, poisoning detection is below threshold. Check two, model supply chain: ModelScan passed, the base model's SBOM is verified, the publisher's signature is valid. Check three, training security: the red-team evaluation scored above the deployment threshold, no critical adversarial perturbations. Check four, deployment security: the harness checklist is complete and passing.

If all four pass, the model deploys, and the SBOM is the certificate of evidence. If any fail, the model does not deploy, and the failed check names the remediation target. This is the MLSecOps analogue of a DevSecOps deployment gate, and the reason it exists is the same: production is a privilege earned by evidence, not a default.

[SLIDE 9 — The tool landscape]

The tools, by lifecycle stage. Four vendors recur.

ModelScan from ProtectAI. A model-file scanner — the ML analogue of a binary vulnerability scanner. Opens a model file — dot-safetensors, dot-pickle, dot-h-five, dot-pt — inspects its metadata and weights, flags pickled Python objects that execute arbitrary code on load, suspicious tensor names, anomalous weight distributions, and known-trojan signatures. ModelScan belongs in the model-supply-chain stage as a deployment gate. The lab implements a minimal ModelScan-style scanner for dot-safetensors.

The ProtectAI suite beyond ModelScan covers training, deployment, and monitoring — ray-based adversarial robustness testing, prompt-injection detection, model-monitoring. The most complete single-vendor stack, but like any single-vendor stack, it has gaps at data security and incident response.

HiddenLayer. Focused on the inference-monitoring and training-security stages. Their runtime product monitors the deployed model for adversarial inputs, drift, and extraction attempts. Their training product detects poisoning in the training pipeline. Strongest when inference monitoring is the priority — for example, a high-throughput production model serving adversarial users.

Robust Intelligence, now part of Cisco. A continuous-validation platform covering training, deployment, and monitoring. The distinguishing property is the continuous framing — the platform runs adversarial tests against the model on a cadence, not just at deployment, catching drift-induced vulnerabilities that emerge after deployment.

No single vendor covers the lifecycle. Assemble tools by stage and threat, and integrate via shared evidence — the model SBOM — not via a single vendor's stack.

[SLIDE 10 — Anti-patterns]

Four anti-patterns, each with its cure.

"We have a CI/CD pipeline, so we are doing MLSecOps." The pipeline covers the transferring primitives but not the five new ones. Cure: extend the pipeline with the ML-specific gates — one per new concern.

Deploying a model without a model scan. A binary scanner does not understand model files; a trojaned model passes. Cure: a model-specific scanner — ModelScan or equivalent — as a deployment gate.

Treating the model as a black box in production. Infrastructure metrics — CPU, latency — miss model-behavior metrics — drift, injection, output harm. Cure: add drift detection, injection detection, and output-harm scoring to the monitoring stack.

No feedback loop from incidents to stages. The incident was contained but the root cause was not mapped to a stage, so the same attack succeeds again. Cure: attribute every incident to the stage where the control failed, and apply the fix to that stage's gate. Incidents feed the lifecycle.

[SLIDE 11 — What you can now do]

Close on what you can now do. Name the six stages and the concern, failure mode, and control for each. Map every stage to existing course content. Explain how MLSecOps extends DevSecOps — the five primitives that transfer and the five that are new. Evaluate the tools by stage and threat, and assemble an integrated toolchain. Build a model scanning pipeline for dot-safetensors.

The lab: a model scanning pipeline that takes a dot-safetensors file, extracts its tensor metadata — names, shapes, dtypes — and runs three checks: tensor-name pattern matching against known-trojan conventions, weight-distribution anomaly detection against known-backdoor signatures, and metadata provenance verification. The scanner produces a deployment-gate report — PASS or FAIL with reasons. The model is a dependency; dependencies get scanned; the scan is the gate.

MLSecOps is not new content — it is the connective discipline that ties C-one's harness engineering, C-two-B's AI security, and C-three's fine-tuning into a single security lifecycle. This module names the discipline and maps the existing content into it. From here, every later module and every real-world engagement is an instance of the lifecycle.