# Diagrams — Module B14: MLSecOps — The ML Security Lifecycle **Module**: B14 — MLSecOps: The ML Security Lifecycle **Diagram count**: 5 **Tool**: Mermaid (primary). Each diagram validated in [Mermaid Live Editor](https://mermaid.live). --- ## Diagram 1 — The Six-Stage MLSecOps Lifecycle (with course-content mapping) **Type**: Horizontal pipeline with stage-to-content mapping **Purpose**: The single orientation diagram. Shows the six stages of the MLSecOps lifecycle in order — data security, model supply chain, training security, deployment security, inference monitoring, incident response — each annotated with its security concern and its mapping to existing course content. This is the connective-tissue diagram: it proves MLSecOps is not new content but the naming of a lifecycle the course already teaches in pieces. **Reading the diagram**: Six stages left to right. Each stage node names the concern; the mapping below each node names the course module that teaches it. The feedback arrow from incident response back to data security closes the lifecycle — incidents feed the earlier stages. ```mermaid flowchart LR S1["STAGE 1\nDATA SECURITY\nprovenance, chain-of-custody,\ndataset signing, poisoning detection\n\nMAPS TO:\nC3 Pillar 1 + C2B B3"] S2["STAGE 2\nMODEL SUPPLY CHAIN\nmodel SBOM, ModelScan,\nregistry verification, hash match\n\nMAPS TO:\nC2B B4/SDD-B07 + B13\nrepresentation attacks"] S3["STAGE 3\nTRAINING SECURITY\nrun integrity, adversarial training,\nred-team eval, FT hardening\n\nMAPS TO:\nC3 Pillars 2-5"] S4["STAGE 4\nDEPLOYMENT SECURITY\nfive-layer harness, C2B defenses,\ndeployment-as-a-gate\n\nMAPS TO:\nC2B B7 + C1 Module 5"] S5["STAGE 5\nINFERENCE MONITORING\nobservability, drift detection,\ninjection detection, output scoring\n\nMAPS TO:\nC2B B8 + C1 Module 10"] S6["STAGE 6\nINCIDENT RESPONSE\nrunbooks, containment, rollback,\nroot-cause mapping, feedback loop\n\nMAPS TO:\nC2B Capstone 2"] S1 -->|data passes| S2 S2 -->|scan passes| S3 S3 -->|eval passes| S4 S4 -->|harness passes| S5 S5 -->|incident detected| S6 S6 -.->|lessons feed back\nto earlier stages| S1 THESIS["MLSecOps is NOT new content.\nIt is the CONNECTIVE DISCIPLINE that names the stages,\ndefines the gates, and runs the cadence.\nEvery stage maps to content already taught;\nMLSecOps adds the lifecycle view."] S6 --> THESIS style S1 fill:#08080c,stroke:rgba(94,234,212,0.4),color:#5eead4 style S2 fill:#08080c,stroke:rgba(94,234,212,0.4),color:#5eead4 style S3 fill:#08080c,stroke:rgba(94,234,212,0.4),color:#5eead4 style S4 fill:#08080c,stroke:rgba(240,168,104,0.4),color:#f0a868 style S5 fill:#08080c,stroke:rgba(240,168,104,0.4),color:#f0a868 style S6 fill:#08080c,stroke:rgba(240,128,128,0.4),color:#f08080 style THESIS fill:#08080c,stroke:#5eead4,stroke-width:1.5px,color:#5eead4 ``` --- ## Diagram 2 — How MLSecOps Extends DevSecOps (what transfers, what is new) **Type**: Two-track comparison **Purpose**: The load-bearing diagram for B14.2. Shows which DevSecOps primitives transfer directly to MLSecOps (the substrate) and which primitives are genuinely new (the extension). Resolves the anti-pattern of "we have a CI/CD pipeline, so we're doing MLSecOps" by showing the five ML-specific concerns the DevSecOps pipeline does not cover. **Reading the diagram**: Left track = the transferring primitives (SBOM, CI/CD gates, signed artifacts, secrets, least privilege). Right track = the five new primitives (model scan, adversarial robustness, drift detection, injection monitoring, representation analysis). The footer is the principle: MLSecOps is DevSecOps as the substrate plus five ML-specific stages on top. ```mermaid flowchart TB subgraph TRANSFER["TRANSFERS FROM DevSecOps (the substrate)"] T1["SBOM — software SBOM -> model SBOM\n(enumerate dependencies, sign, verify)"] T2["CI/CD GATES — code gates -> model gates\n(data, scan, eval, harness checks)"] T3["SIGNED ARTIFACTS — image signatures ->\nmodel + dataset signatures (.safetensors)"] T4["SECRETS MANAGEMENT — vault -> vault\n(+ memorized-secrets risk)"] T5["LEAST PRIVILEGE — service perms ->\ntraining pipeline, model server perms"] end subgraph NEW["NEW IN MLSecOps (the extension)"] N1["MODEL SCANNING — weight/metadata analysis\nfor backdoors (binary scanners miss this)"] N2["ADVERSARIAL ROBUSTNESS — perturb inputs,\nmeasure output change (no software analogue)"] N3["DRIFT DETECTION — input distribution vs\ntraining baseline (runtime concern, not static)"] N4["PROMPT-INJECTION MONITORING — score inputs\nfor injection signatures (LLM-specific)"] N5["REPRESENTATION-LAYER ANALYSIS — the model's\ninternal geometry as a security surface"] end PRINCIPLE["MLSecOps = DevSecOps (the substrate)\n+ FIVE ML-SPECIFIC STAGES (the extension).\nNaively applying DevSecOps to ML produces gaps\nat every new stage. Extend, do not replace."] TRANSFER --> PRINCIPLE NEW --> PRINCIPLE style TRANSFER fill:#14141f,stroke:rgba(94,234,212,0.5),color:#e4e4e8 style NEW fill:#14141f,stroke:rgba(240,168,104,0.5),color:#e4e4e8 style T1 fill:#08080c,stroke:rgba(94,234,212,0.3),color:#5eead4 style T2 fill:#08080c,stroke:rgba(94,234,212,0.3),color:#5eead4 style T3 fill:#08080c,stroke:rgba(94,234,212,0.3),color:#5eead4 style T4 fill:#08080c,stroke:rgba(94,234,212,0.3),color:#5eead4 style T5 fill:#08080c,stroke:rgba(94,234,212,0.3),color:#5eead4 style N1 fill:#08080c,stroke:rgba(240,168,104,0.3),color:#f0a868 style N2 fill:#08080c,stroke:rgba(240,168,104,0.3),color:#f0a868 style N3 fill:#08080c,stroke:rgba(240,168,104,0.3),color:#f0a868 style N4 fill:#08080c,stroke:rgba(240,168,104,0.3),color:#f0a868 style N5 fill:#08080c,stroke:rgba(240,168,104,0.3),color:#f0a868 style PRINCIPLE fill:#08080c,stroke:#5eead4,stroke-width:1.5px,color:#5eead4 ``` --- ## Diagram 3 — The Deployment Gate (four composed checks, evidence in the SBOM) **Type**: Gate-composition flow **Purpose**: Shows the single most important MLSecOps practice — the deployment gate — as the composition of four stage-level checks. A model does not reach production until all four pass, and the evidence is recorded in the model SBOM as the certificate. This is the practical anchor of the lifecycle: the gate is enforceable, the evidence is auditable, and production is a privilege earned by evidence. **Reading the diagram**: Four check nodes feed into the gate. Each check produces evidence. The gate composes the evidence into a single PASS/FAIL decision. If PASS, the model deploys with its SBOM as the certificate. If FAIL on any check, the model does not deploy and the failed check names the remediation target. ```mermaid flowchart TB C1["CHECK 1 — DATA SECURITY\ntraining corpus hash matches signed manifest\npoisoning detection below threshold\nEvidence: data-provenance report"] C2["CHECK 2 — MODEL SUPPLY CHAIN\nModelScan passed on the model file\nbase model SBOM verified, publisher sig valid\nEvidence: model-scan report + lineage"] C3["CHECK 3 — TRAINING SECURITY\nred-team eval above deployment threshold\nadversarial robustness: no critical perturbations\nEvidence: eval scores + robustness report"] C4["CHECK 4 — DEPLOYMENT SECURITY\nfive-layer harness checklist complete\nC2B defenses configured and passing\nEvidence: harness-checklist report"] GATE["THE DEPLOYMENT GATE\nComposes all four checks into one decision.\nIf ALL pass -> DEPLOY (SBOM is the certificate).\nIf ANY fail -> BLOCK (failed check names the fix)."] C1 --> GATE C2 --> GATE C3 --> GATE C4 --> GATE DEPLOY["DEPLOY\nmodel serves traffic\nSBOM is the certificate of evidence"] BLOCK["BLOCK\nmodel does NOT deploy\nfailed check names the remediation target"] GATE -->|all four pass| DEPLOY GATE -->|any fail| BLOCK style C1 fill:#08080c,stroke:rgba(94,234,212,0.3),color:#5eead4 style C2 fill:#08080c,stroke:rgba(94,234,212,0.3),color:#5eead4 style C3 fill:#08080c,stroke:rgba(94,234,212,0.3),color:#5eead4 style C4 fill:#08080c,stroke:rgba(240,168,104,0.3),color:#f0a868 style GATE fill:#08080c,stroke:#f0a868,stroke-width:1.5px,color:#f0a868 style DEPLOY fill:#08080c,stroke:rgba(130,224,170,0.5),color:#82e0aa style BLOCK fill:#08080c,stroke:#f08080,stroke-width:1.5px,color:#f08080 ``` --- ## Diagram 4 — The MLSecOps Tool Landscape (vendors by lifecycle stage) **Type**: Stage-to-tool coverage matrix (flowchart form) **Purpose**: Maps the four MLSecOps vendors (ModelScan, ProtectAI suite, HiddenLayer, Robust Intelligence) to the lifecycle stages they cover and the threats they address. The discipline is to evaluate tools by stage coverage and assemble an integrated toolchain, rather than buying one product and expecting it to cover the lifecycle. **Reading the diagram**: The six lifecycle stages run across the top. Each vendor node lists the stages it covers and the threats it addresses. The footer is the integration principle: no single vendor covers the lifecycle; assemble by stage, integrate via shared evidence (the SBOM). ```mermaid flowchart TB STAGES["LIFECYCLE STAGES:\n1. Data security | 2. Model supply chain | 3. Training security\n4. Deployment security | 5. Inference monitoring | 6. Incident response"] V1["ModelScan (ProtectAI)\nCOVERS: Stage 2 (model supply chain)\nTHREAT: trojaned models, malicious weights,\n pickle deserialization, anomalous tensors\nSTRENGTH: the canonical file-scanning gate"] V2["ProtectAI suite (beyond ModelScan)\nCOVERS: Stages 3 (training) + 4 (deployment) + 5 (monitoring)\nTHREAT: adversarial inputs, prompt injection,\n production drift, robustness gaps\nSTRENGTH: most complete single-vendor stack;\n gaps at data security + incident response"] V3["HiddenLayer\nCOVERS: Stages 3 (training poisoning) + 5 (inference runtime)\nTHREAT: adversarial inputs, model extraction,\n training-data poisoning, runtime drift\nSTRENGTH: strongest inference-monitoring\n for high-throughput adversarial serving"] V4["Robust Intelligence (Cisco)\nCOVERS: Stages 3 (training) + 4 (deployment) + 5 (continuous)\nTHREAT: robustness regression post-deployment,\n poisoning, behavior drift over time\nSTRENGTH: CONTINUOUS validation — adversarial\n tests on a cadence, not just at deployment"] INTEGRATION["INTEGRATION PRINCIPLE:\nNo single vendor covers the lifecycle.\nAssemble tools by stage and threat.\nIntegrate via SHARED EVIDENCE (the model SBOM)\nnot via a single vendor's stack."] STAGES --> V1 STAGES --> V2 STAGES --> V3 STAGES --> V4 V1 --> INTEGRATION V2 --> INTEGRATION V3 --> INTEGRATION V4 --> INTEGRATION style STAGES fill:#08080c,stroke:rgba(94,234,212,0.5),color:#5eead4 style V1 fill:#08080c,stroke:rgba(94,234,212,0.3),color:#5eead4 style V2 fill:#08080c,stroke:rgba(240,168,104,0.3),color:#f0a868 style V3 fill:#08080c,stroke:rgba(240,168,104,0.3),color:#f0a868 style V4 fill:#08080c,stroke:rgba(240,168,104,0.3),color:#f0a868 style INTEGRATION fill:#08080c,stroke:#5eead4,stroke-width:1.5px,color:#5eead4 ``` --- ## Diagram 5 — The Incident-Response Feedback Loop (incidents feed the lifecycle) **Type**: Closed-loop feedback flow **Purpose**: Shows the property that makes MLSecOps a lifecycle rather than a pipeline: the incident-response stage feeds lessons back into the earlier stages. Every incident is attributed to the stage where the control failed, and the fix is applied to that stage's gate. Without this loop, the same attack succeeds again next quarter. This is the diagram that distinguishes a lifecycle from a checklist. **Reading the diagram**: The six stages form the outer loop (from Diagram 1). The inner feedback paths show specific incident classes mapping to specific stage fixes: a prompt-injection breach feeds new injection-detection rules into the inference-monitoring stage; a supply-chain compromise feeds a new ModelScan signature into the model-supply-chain stage; a drift incident feeds a new threshold into the inference monitor. The principle: incidents are the lifecycle's learning signal. ```mermaid flowchart TB S1["Stage 1\nData security"] S2["Stage 2\nModel supply chain"] S3["Stage 3\nTraining security"] S4["Stage 4\nDeployment security"] S5["Stage 5\nInference monitoring"] S6["Stage 6\nIncident response"] S1 --> S2 --> S3 --> S4 --> S5 --> S6 F1["FEEDBACK: supply-chain compromise\n-> new ModelScan signature to Stage 2\n-> new SBOM verification rule to Stage 2"] F2["FEEDBACK: prompt-injection breach\n-> new injection-detection rule to Stage 5\n-> new red-team eval case to Stage 3"] F3["FEEDBACK: drift incident\n-> new threshold to Stage 5 monitor\n-> new training data to Stage 1"] F4["FEEDBACK: data-poisoning incident\n-> new provenance check to Stage 1\n-> new poisoning-detection rule to Stage 1"] S6 -.-> F1 -.-> S2 S6 -.-> F2 -.-> S5 S6 -.-> F3 -.-> S1 S6 -.-> F4 -.-> S1 PRINCIPLE["Without the feedback loop, MLSecOps is a CHECKLIST\n(each stage checked once at deployment).\nWITH the loop, it is a LIFECYCLE\n(each incident strengthens the earlier stages).\nIncidents are the lifecycle's learning signal.\nEvery incident is attributed to a stage; the fix\nis applied to THAT stage's gate."] S6 --> PRINCIPLE style S1 fill:#08080c,stroke:rgba(94,234,212,0.4),color:#5eead4 style S2 fill:#08080c,stroke:rgba(94,234,212,0.4),color:#5eead4 style S3 fill:#08080c,stroke:rgba(94,234,212,0.4),color:#5eead4 style S4 fill:#08080c,stroke:rgba(240,168,104,0.4),color:#f0a868 style S5 fill:#08080c,stroke:rgba(240,168,104,0.4),color:#f0a868 style S6 fill:#08080c,stroke:rgba(240,128,128,0.4),color:#f08080 style F1 fill:#08080c,stroke:rgba(94,234,212,0.3),color:#5eead4 style F2 fill:#08080c,stroke:rgba(240,168,104,0.3),color:#f0a868 style F3 fill:#08080c,stroke:rgba(240,168,104,0.3),color:#f0a868 style F4 fill:#08080c,stroke:rgba(94,234,212,0.3),color:#5eead4 style PRINCIPLE fill:#08080c,stroke:#5eead4,stroke-width:1.5px,color:#5eead4 ``` --- ## Validation notes - All five diagrams use the course design system colors: `#14141f` panel fill, `#08080c` deep background for nested nodes, `#5eead4` teal accent for the build-time stages (data, supply-chain, training) and the principle/thesis nodes, `#f0a868` warn for the deployment and runtime stages (deployment, monitoring) and the gate/transitions, `#f08080` danger for the incident-response stage and the block/impact nodes. `#82e0aa` is reserved for the single DEPLOY success node in Diagram 3. `#e4e4e8` / `#9494a0` for text. - Paste each into [Mermaid Live Editor](https://mermaid.live) to render. All use stable Mermaid syntax (`flowchart TB/LR`, `subgraph`, dotted feedback arrows `-.->`) supported in current Mermaid (v10.4+). - For the slide deck (artifact 03), these are rendered as static captures from Mermaid Live, inlined into reveal.js. - The color mapping is consistent with the SDD deep-dives and carries semantic load: teal (the build-time stages) = where the model is constructed and the defenses are built in; warn (the deployment and runtime stages) = where the model is exposed and the defenses are tested; danger (incident response) = where the defenses failed and the lifecycle must learn. This lets the reader track which phase of the lifecycle a node belongs to across all five diagrams.