MLSecOps

The ML Security Lifecycle · Module B14 · Course 2B

60 minutes · The connective discipline that ties C1, C2B, and C3 into a single security lifecycle

MLSecOps is not new content. It 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.

Pillar 4 — Frameworks & Governance

The thesis — MLSecOps is the connective discipline

What the course taught (in pieces)

C1: harness engineering. C2B: AI security attacks and defenses. C3: fine-tuning. Each module is complete. Each is a piece.

What MLSecOps adds

The lifecycle view: the naming, the ordering, the gates between stages, the toolchain, and the operating cadence. The connective tissue that turns pieces into a discipline.

The value is the lifecycle, not the content. A team that learned C1, C2B, and C3 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.

The six stages — one lifecycle, mapped to existing content

Stage	Security concern	Maps to
1. Data security	Provenance, chain-of-custody, dataset signing, poisoning detection	C3 Pillar 1 + C2B B3 (Memory Poisoning)
2. Model supply chain	Model SBOM, ModelScan, registry verification, hash match	C2B B4 / SDD-B07 + B13 representation attacks
3. Training security	Run integrity, adversarial training, red-team eval, FT hardening	C3 Pillars 2–5
4. Deployment security	Five-layer harness, C2B defenses, deployment-as-a-gate	C2B B7 + C1 Module 5
5. Inference monitoring	Observability, drift detection, injection detection, output scoring	C2B B8 + C1 Module 10
6. Incident response	Runbooks, containment, rollback, root-cause mapping, feedback	C2B Capstone 2

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

Stage 1 + 2 — data security & model supply chain

Data security

Failure: poisoning (clean-label attack), tampered corpus, untrusted third-party dataset. Control: provenance, chain-of-custody, dataset signing, poisoning detection (statistical anomaly on the training distribution).

Model supply chain

Failure: trojaned base model, typosquat, evil-twin with valid signature, representation-level backdoor. Control: model SBOM, ModelScan, registry verification, hash matching. The model is a dependency — treat it like one.

The ASI08 supply-chain pattern (signed-but-malicious) from SDD-B01 applies at the model layer too: a signature verifies the publisher, not the model's benignity. The model SBOM (SDD-B07) generalizes to the model itself.

Stage 3 + 4 — training & deployment security

Training security

Two concerns: (1) training-run integrity (no unauthorized modification of the run); (2) adversarial robustness (the model resists the threats it will face). Controls: access-controlled infra, hashed data, version-controlled hyperparams, adversarial training, red-team eval before deployment.

Deployment security

Failure: the un-harnessed model (served without input validation, tool contracts, sandbox, output handling). Control: the C1 five-layer harness + the C2B defenses. Deployment is a gate, not an event.

Deployment is the gate between training and production. The model does not reach production until the harness checklist, the red-team evaluation, and the model scan have all passed.

Stage 5 + 6 — inference monitoring & incident response

Inference monitoring

Concern: no model is safe at rest; safety is a property of the running system. Threats: deployed attacks (injection, hijack), drift, slow-compromise, silent hallucination. Controls: observability substrate, anomaly detection, injection detection, drift detection.

Incident response

Failure: undetected, slow-contained, repeated, or un-attributed incidents. Controls: runbooks per incident class, the Capstone 2 engagement as rehearsal, root-cause mapping to a lifecycle stage, and the feedback loop that feeds lessons back into earlier stages.

The feedback loop is what makes MLSecOps a lifecycle, not a checklist. Every incident is attributed to the stage where the control failed, and the fix is applied to that stage's gate. Without the loop, the same attack succeeds again next quarter.

How MLSecOps extends DevSecOps

Transfers from DevSecOps

SBOM (software → model), CI/CD gates, signed artifacts (.safetensors), secrets management, least privilege. The substrate.

New in MLSecOps

Five concerns with no software analogue: (1) model scanning (weight analysis, not binary scanning), (2) adversarial robustness (continuous surface, no clean boundary), (3) drift detection (runtime, not static), (4) prompt-injection monitoring (LLM-specific), (5) representation-layer analysis (the model's internal geometry).

"We have a CI/CD pipeline, so we're doing MLSecOps" is the anti-pattern. The pipeline covers the transferring primitives but not the five new ones. The model deploys without a scan, without robustness eval, without drift detection, without injection monitoring. Cure: extend, do not replace.

The deployment gate — four composed checks

Check	What must pass	Evidence
1. Data security	Corpus hash matches signed manifest; poisoning detection below threshold	Data-provenance report
2. Model supply chain	ModelScan passed; base model SBOM verified; publisher signature valid	Model-scan report + lineage
3. Training security	Red-team eval above threshold; no critical adversarial perturbations	Eval scores + robustness report
4. Deployment security	Five-layer harness checklist complete; C2B defenses configured	Harness-checklist report

If ALL pass → DEPLOY (the SBOM is the certificate). If ANY fail → BLOCK (the failed check names the remediation target). Production is a privilege earned by evidence, not a default.

The tool landscape — vendors by lifecycle stage

Tool	Stages covered	Threat addressed
ModelScan (ProtectAI)	Stage 2 (model supply chain)	Trojaned models, malicious weights, pickle deserialization, anomalous tensors. The canonical file-scanning gate.
ProtectAI suite	Stages 3, 4, 5	Adversarial inputs, prompt injection, production drift, robustness gaps. Most complete single-vendor stack; gaps at data + incident.
HiddenLayer	Stages 3 (poisoning) + 5 (runtime)	Adversarial inputs, model extraction, training poisoning, runtime drift. Strongest for high-throughput adversarial serving.
Robust Intelligence (Cisco)	Stages 3, 4, 5 (continuous)	Robustness regression post-deployment, poisoning, behavior drift. Continuous validation on a cadence, not just at deployment.

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

Anti-patterns

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

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) as a deployment gate.

Treating the model as a black box in production. Infrastructure metrics (CPU, latency) miss model-behavior metrics (drift, injection). 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. The same attack succeeds again. Cure: attribute every incident to a stage; apply the fix to that stage's gate.

What you can now do

Name the six stages of the MLSecOps lifecycle and describe the security concern, the failure mode, and the control for each.
Map every stage to existing course content (C3 Pillar 1 + B3, B4/SDD-B07 + B13, C3 Pillars 2–5, B7 + C1 M5, B8 + C1 M10, Capstone 2).
Explain how MLSecOps extends DevSecOps: the five primitives that transfer and the five that are new — and why naively applying DevSecOps to ML produces gaps.
Evaluate the MLSecOps tools (ModelScan, ProtectAI, HiddenLayer, Robust Intelligence) by stage and threat, and assemble an integrated toolchain.
Build a model scanning pipeline that checks a .safetensors file for known backdoor patterns — the canonical deployment gate.

The lab: a model scanning pipeline for .safetensors — extract tensor metadata, run three checks (tensor-name patterns, weight-distribution anomalies, provenance verification), produce a deployment-gate report (PASS/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 C1, C2B, and C3 into one lifecycle.