{ "module": "B14", "title": "MLSecOps — The ML Security Lifecycle", "course": "2B — Securing & Attacking Harnesses and LLMs", "version": "1.0", "duration_minutes": 35, "total_questions": 15, "bloom_distribution": { "recall": 3, "application": 6, "analysis": 6 }, "passing_score_percent": 70, "questions": [ { "id": "B14-001", "bloom": "recall", "type": "multiple_choice", "prompt": "Which of the following is the correct ordered list of the six stages of the MLSecOps lifecycle as taught in this module?", "options": [ "Data security → model supply chain → training security → deployment security → inference monitoring → incident response", "Data security → training security → model supply chain → deployment security → inference monitoring → incident response", "Model supply chain → data security → training security → deployment security → inference monitoring → incident response", "Data security → model supply chain → deployment security → training security → inference monitoring → incident response" ], "answer_index": 0, "rationale": "The six stages, in order, are data security, model supply chain, training security, deployment security, inference monitoring, incident response. The ordering reflects the artifact's lifecycle: secure the data, verify the model dependency, secure the training run, deploy the harness, monitor the running system, respond to incidents. Options B, C, and D all mis-order stages; the model supply chain (verifying the base model) must come before training (which uses the base model), and training must come before deployment." }, { "id": "B14-002", "bloom": "recall", "type": "multiple_choice", "prompt": "The module's central insight about MLSecOps is that it is:", "options": [ "A new set of security techniques invented specifically for the ML lifecycle, with no analogue in DevSecOps", "The connective discipline that names, orders, and gates content already taught in C1, C2B, and C3 — not new content", "A vendor product category led by ProtectAI, HiddenLayer, and Robust Intelligence", "The practice of running adversarial robustness tests on a continuous cadence after deployment" ], "answer_index": 1, "rationale": "The load-bearing insight (stated verbatim in the lede) is that 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. Every stage maps to already-taught content; MLSecOps adds the naming, ordering, gates, toolchain, and operating cadence. Options A, C, and D each confuse one component of MLSecOps (new primitives, tool vendors, continuous validation) with the whole discipline." }, { "id": "B14-003", "bloom": "recall", "type": "multiple_choice", "prompt": "ModelScan, ProtectAI's open-source scanner, is the canonical tool for which lifecycle stage?", "options": [ "Data security (statistical poisoning detection)", "Model supply chain (model-file scanning at the deployment gate)", "Training security (adversarial robustness evaluation)", "Inference monitoring (runtime anomaly detection)" ], "answer_index": 1, "rationale": "ModelScan is a model-file scanner — the ML analogue of a binary vulnerability scanner. It opens a model file (.safetensors, .pickle, .h5, .pt), inspects its metadata and weights, and flags known-bad patterns (pickled Python objects, suspicious tensor names, anomalous weight distributions, known-trojan signatures). It belongs in the model-supply-chain stage as a deployment gate: the model does not deploy until ModelScan passes. The other stages use different tools (statistical poisoning detection for data security, red-team eval for training, runtime monitors for inference)." }, { "id": "B14-004", "bloom": "application", "type": "multiple_choice", "prompt": "A team downloads a base model from a public registry, verifies that the publisher's signature is valid, and deploys. The model turns out to be trojaned — it produces attacker-chosen outputs on a trigger. Which anti-pattern did the team fall into, and what is the cure?", "options": [ "Anti-pattern: treating the model as a black box. Cure: add drift detection to the monitoring stack.", "Anti-pattern: 'we have a CI/CD pipeline, so we are doing MLSecOps.' Cure: add the five new ML-specific gates.", "Anti-pattern: deploying a model without a model scan. Cure: a model-specific scanner (ModelScan or equivalent) as a deployment gate — the signature verifies the publisher, not the benignity.", "Anti-pattern: no incident runbook. Cure: a runbook per ML-incident class with containment, rollback, and communication." ], "answer_index": 2, "rationale": "A signature verifies the publisher's identity, not the artifact's benignity — a malicious publisher can produce a signed trojan. The team's failure was omitting the model scan, which would have analyzed the weights for known-trojan signatures. The cure is a model-specific scanner as a deployment gate. This is the ASI08 signed-but-malicious pattern (taught in SDD-B01) now at the model layer. Options A, B, and D name real anti-patterns but do not match this failure mode." }, { "id": "B14-005", "bloom": "application", "type": "multiple_choice", "prompt": "Your team has a mature DevSecOps pipeline: CI/CD gates, signed container images, binary vulnerability scans, infrastructure monitoring (CPU, latency, request rate), and incident runbooks for outages. You are about to deploy your first LLM-based agent. Which of the following gaps is NOT closed by your existing DevSecOps practices?", "options": [ "The model file is signed by the producer — your existing artifact-signing practice transfers directly.", "The training corpus may be poisoned with clean-label examples that pass label inspection — no DevSecOps primitive detects this.", "The deployed model will be exposed to natural-language prompt-injection inputs that no DevSecOps logging stack scores.", "The model's behavior will drift over time as the input distribution shifts, but infrastructure metrics will show a healthy system throughout the degradation." ], "answer_index": 0, "rationale": "Option A is the one practice that DOES transfer — artifact signing is a DevSecOps primitive that applies to model files (with .safetensors as the format). Options B, C, and D are all genuine gaps: clean-label poisoning requires statistical poisoning detection (no DevSecOps analogue), prompt-injection monitoring requires content-level input scoring (no DevSecOps analogue), and drift detection requires model-behavior monitoring (infrastructure metrics miss it). The question asks for the option that is NOT a gap — that is A." }, { "id": "B14-006", "bloom": "application", "type": "multiple_choice", "prompt": "You are building a deployment gate for a fine-tuned model. The data-security check passed (corpus hash matches manifest), the model-supply-chain check passed (ModelScan clean, base model SBOM verified), and the training-security check passed (red-team eval above threshold). During the deployment-security check, you discover the harness is missing the output-handling layer. What is the correct action?", "options": [ "Deploy — three of four checks passed, and the output-handling layer can be added in a follow-up release.", "Do not deploy — the deployment gate is a composition; any single failed check blocks deployment until remediated and the evidence is re-recorded in the SBOM.", "Deploy but file a ticket — the model itself is safe, only the harness is incomplete.", "Deploy if the missing layer is rated low-severity; otherwise, escalate to a security lead for a risk-acceptance sign-off." ], "answer_index": 1, "rationale": "The deployment gate is a composition of four checks: data security, model supply chain, training security, deployment security. A model that fails ANY check does not deploy — production is a privilege earned by evidence, not a default. The harness missing its output-handling layer is a deployment-security failure (the C1 five-layer harness is incomplete), so the gate fails. Options A, C, and D all weaken the gate by allowing deployment on partial evidence; risk-acceptance overrides (D) are sometimes used in practice but are explicitly NOT the MLSecOps-as-taught discipline, which treats the gate as non-negotiable." }, { "id": "B14-007", "bloom": "application", "type": "multiple_choice", "prompt": "A clean-label data-poisoning attack is discovered in your training corpus after deployment. Which MLSecOps stage's control failed, and what is the correct feedback-loop action?", "options": [ "Stage 5 (inference monitoring) failed; the cure is to improve drift detection to catch the resulting behavior.", "Stage 1 (data security) failed; the cure is to strengthen the data-security gate (statistical poisoning detection above threshold, dataset signing) and re-run the lifecycle.", "Stage 6 (incident response) failed; the cure is to write a runbook for clean-label attacks.", "Stage 3 (training security) failed; the cure is to retrain with adversarial examples that include the clean-label pattern." ], "answer_index": 1, "rationale": "The clean-label attack is a data-poisoning variant — it injects correctly-labeled but feature-crafted examples into the training corpus. The control that should have caught it is at Stage 1 (data security): statistical anomaly detection on the feature distribution (not label inspection, which clean-label defeats), dataset signing, provenance tracking. The feedback-loop action is to strengthen the Stage 1 gate and re-run the lifecycle from data security onward. Options A, C, and D mis-attribute the failure to downstream stages; while those stages might detect or respond to the consequences, the root cause is at Stage 1." }, { "id": "B14-008", "bloom": "application", "type": "multiple_choice", "prompt": "You need to select a monitoring tool for a high-throughput production model that serves adversarial users (a public-facing fraud-detection model). The primary concern is detecting adversarial inputs, drift, and extraction attempts at runtime. Which tool is the strongest fit?", "options": [ "ModelScan — it scans model files for known-trojan signatures at the deployment gate.", "Robust Intelligence — it runs adversarial tests on a continuous cadence to catch drift-induced vulnerabilities.", "HiddenLayer runtime — its product is focused on monitoring the deployed model for adversarial inputs, drift, and extraction attempts.", "The ProtectAI suite — its model-monitoring component covers production inference." ], "answer_index": 2, "rationale": "HiddenLayer is described in the module as the strongest choice when inference monitoring is the priority — its runtime product monitors the deployed model for adversarial inputs, drift, and extraction attempts (the exact three concerns in the question). Robust Intelligence (B) is also relevant but its distinguishing property is continuous adversarial testing rather than runtime attack detection; it is better suited to catching drift-induced vulnerabilities than live extraction attempts. ModelScan (A) is a deployment-gate file scanner, not a runtime monitor. ProtectAI (D) has a monitoring component but the module positions HiddenLayer as the strongest single choice for the inference-monitoring stage." }, { "id": "B14-009", "bloom": "analysis", "type": "multiple_choice", "prompt": "A team says: 'We have a CI/CD pipeline, we sign our artifacts, we scan for vulnerabilities — we are doing MLSecOps.' Which of the following best characterizes what they are doing and what they are missing?", "options": [ "They are doing the five primitives that transfer from DevSecOps (SBOM, gates, signing, secrets, least privilege); they are missing the five primitives that are new (model scanning, adversarial robustness, drift detection, prompt-injection monitoring, representation-layer analysis). The cure is to extend, not abandon, the DevSecOps substrate.", "They are doing the five new primitives; they are missing the DevSecOps substrate. The cure is to adopt DevSecOps from scratch.", "They are doing MLSecOps correctly — the transferring primitives are sufficient for ML deployments.", "They are doing neither — MLSecOps is a vendor product, not a practice, and must be purchased." ], "answer_index": 0, "rationale": "The anti-pattern 'we have a CI/CD pipeline, so we are doing MLSecOps' is dangerous precisely because the team IS doing the transferring primitives correctly — they just are not doing the five new primitives that have no DevSecOps analogue. The model will deploy without a model scan (binary scanners do not understand model files), without robustness eval, without drift detection, without injection monitoring, without representation analysis. The cure is to take the DevSecOps pipeline as the substrate and extend it with the five ML-specific gates — one per new concern. The transferring primitives are necessary but not sufficient." }, { "id": "B14-010", "bloom": "analysis", "type": "multiple_choice", "prompt": "Consider two models. Model A is a static base model downloaded from a registry and verified at deployment. Model B is a fine-tuned model served in production whose input distribution shifts weekly. Which statement best explains why the deployment gate for Model A is a discrete pass/fail while Model B's monitoring is continuous?", "options": [ "Model A is smaller than Model B, so its scan terminates faster.", "Model A is a static artifact scanned at a discrete moment; the scan is deterministic and terminates. Model B is a running system whose inputs are unbounded and whose behavior is probabilistic; its checks are statistical scores that never terminate and can fire alerts but rarely produce a clean pass.", "Model A is a supply-chain concern; Model B is a training concern — they belong to different stages.", "The deployment gate applies to both models equally; Model B is simply rescanned on a weekly cadence." ], "answer_index": 1, "rationale": "The model-supply-chain stage operates on a static artifact (the file) at a discrete point (before deployment); the scan is deterministic and terminates with a clean pass or fail. The inference-monitoring stage operates on a running system whose inputs are unbounded (you cannot enumerate every possible input) and whose behavior is probabilistic (the same input can produce different outputs); the checks are statistical scores (drift score, injection score, harm score) that never terminate. This is why the deployment gate composes four binary checks but the monitoring stage runs continuously with alerting thresholds." }, { "id": "B14-011", "bloom": "analysis", "type": "multiple_choice", "prompt": "An incident occurs: a prompt-injection attack exfiltrated data through a tool the agent had access to. The incident-response team contains the attack, writes a runbook, and closes the ticket. Three months later, the same attack succeeds again. Which MLSecOps discipline was missing?", "options": [ "The incident-response runbook — it should have been written before the first incident, not after.", "The Capstone 2 rehearsal — the team should have dry-run the incident before it occurred.", "The feedback loop — the incident was contained but the root cause was not mapped to the lifecycle stage where the control failed (was it a deployment-security failure for granting the tool, an inference-monitoring failure for not detecting the injection, or a training-security failure for a model susceptible to injection?), so no gate was improved and the same attack recurred.", "The model scan — if the scan had been run, it would have caught the injection vulnerability." ], "answer_index": 2, "rationale": "The feedback loop is what makes MLSecOps a lifecycle rather than a checklist. Without it, the incident was contained but the lifecycle was not improved — the root cause was not attributed to the stage where the control failed, and no gate was strengthened. The same attack succeeds again because nothing changed. Option A (runbook timing) and B (rehearsal) are real practices but would not have prevented recurrence. Option D is wrong because model scans detect trojans and serialization attacks, not prompt-injection susceptibility. The defining failure is the missing feedback loop." }, { "id": "B14-012", "bloom": "analysis", "type": "multiple_choice", "prompt": "A vendor offers a single product that covers the model-supply-chain scan, the runtime monitor, and the incident-response runbook generator — three of the six MLSecOps stages. Your team is tempted to standardize on it. Which principle from the module should govern this decision?", "options": [ "Single-vendor lock-in is preferable because it reduces integration overhead; adopt the product for all three stages.", "No single vendor covers the lifecycle; evaluate tools by stage and threat, assemble an integrated toolchain, and integrate via shared evidence (the model SBOM) rather than via a single vendor's stack. The vendor's product may be excellent at one stage and weak at another.", "Adopt the vendor for the model-supply-chain scan only; build the monitoring and incident-response stages in-house.", "Reject the vendor — MLSecOps requires six separate tools, one per stage." ], "answer_index": 1, "rationale": "The module's explicit guidance: no single tool covers the lifecycle, and single-vendor lock-in is a named anti-pattern. The discipline is to evaluate tools by stage and threat, assemble an integrated toolchain, and integrate via shared evidence — the model SBOM carries the evidence forward across tools and stages. The vendor's product may be the best at one stage (e.g., the file scan) and weak at another (e.g., the runbook generator), and locking in across all three would leave the weak stage as a gap. Option C is reasonable in practice but is an implementation detail, not the governing principle. Option D is wrong — some tools legitimately cover multiple stages." }, { "id": "B14-013", "bloom": "analysis", "type": "multiple_choice", "prompt": "The module argues that adversarial robustness is a genuinely new MLSecOps primitive with no DevSecOps analogue. Which property of ML systems (vs. software systems) is the root cause of this difference?", "options": [ "ML systems process natural language; software systems process structured data.", "ML systems are deployed on GPUs; software systems are deployed on CPUs.", "A software system either has a bug or it does not (adversarial inputs exploit the bug deterministically); a model has a continuous robustness surface — a space of inputs, some handled correctly and some not, with no clean boundary — so robustness is a measurable continuous property rather than a binary one.", "ML systems are probabilistic; software systems are deterministic." ], "answer_index": 2, "rationale": "The root cause is the continuous-robustness-surface property: a model maps a continuous input space to outputs, and the boundary between inputs handled correctly and inputs handled incorrectly is itself a continuous manifold with no clean edge. Software has bugs (discrete defects) that adversarial inputs exploit deterministically — fix the bug, the adversarial input stops working. A model has no 'bug' to fix; it has a robustness surface to measure and improve, tested by perturbing inputs and measuring output change. Option D (probabilistic vs deterministic) is related but is a consequence, not the root cause; the root cause is the continuous-surface geometry." }, { "id": "B14-014", "bloom": "analysis", "type": "multiple_choice", "prompt": "The model SBOM is described as serving two distinct roles in the MLSecOps lifecycle. Which pair correctly identifies them?", "options": [ "(1) A list of model hyperparameters; (2) a hash of the model file.", "(1) An enumeration of the model's lineage (base model, dataset, training run, evaluation results) signed by the producer; (2) the deployment gate's certificate of evidence (records that data, scan, eval, and harness checks all passed), carried forward so the gate verifies the full chain rather than re-checking each stage.", "(1) A license manifest for open-source model dependencies; (2) a vulnerability feed subscribed to by the deployment gate.", "(1) A training log of loss curves; (2) a monitoring dashboard for production drift." ], "answer_index": 1, "rationale": "The model SBOM is both a manifest (what is in this model — its lineage) and an attestation (why this model is allowed to deploy — the gate's evidence). As an enumeration, it lists the base model, dataset, fine-tuning run, and evaluation results, signed by the producer and verified by the consumer. As a certificate, it records that the data-security check passed, the model scan passed, the red-team eval scored above threshold, and the harness checklist passed — so the deployment gate can verify the full chain of evidence without re-running every check. The SBOM is the integration point across tools and stages." }, { "id": "B14-015", "bloom": "application", "type": "multiple_choice", "prompt": "You are implementing the .safetensors scanner from the lab. The format is described as 'safe' — it does not execute arbitrary code on load, unlike .pickle. Given this, what does the scan focus on, and why is the format's safety not the end of the security story?", "options": [ "The scan focuses on deserialization safety — checking that the file does not contain executable Python. The format's safety means no scan is needed.", "The scan focuses on the CONTENT of the tensors (tensor-name patterns matching known-trojan conventions, weight-distribution anomalies against known-backdoor signatures, metadata provenance verification), because a backdoor can be encoded in the statistical structure of the weights themselves — format-level deserialization safety does not prevent a trojaned model from being loaded and served.", "The scan focuses on the file's byte-level hash; if it matches the producer's published hash, the model is safe.", "The scan focuses on the model's architecture (number of layers, hidden size); architectures outside the published norm are flagged." ], "answer_index": 1, "rationale": ".safetensors eliminates the deserialization attack vector (no arbitrary code execution on load), but it does not eliminate the content-level threat: a backdoor can be encoded in the statistical structure of millions of floating-point weights, invisible to any byte-level inspection. The scan therefore focuses on the content — tensor names (matching known-trojan conventions), weight distributions (anomalies matching known-backdoor signatures), and metadata (provenance fields). Option A and C are insufficient: format safety and hashing address different threats (deserialization and tampering) but not the trojan. Option D is wrong because architecture is not the attack surface — the weights are." } ] }