"front"	"back"	"tags"
"What is MLSecOps, in one sentence?"	"MLSecOps is the application of security practices to the ML development and deployment lifecycle — analogous to how DevSecOps applied security to the software lifecycle. The load-bearing insight: MLSecOps is not new content; it is the connective discipline that names the stages, defines the gates, specifies the toolchain, and runs the cadence, turning C1 (harness engineering), C2B (AI security), and C3 (fine-tuning) into a single lifecycle."	"b14::mlsecops::definition"
"Name the six stages of the MLSecOps lifecycle, in order."	"1. Data security. 2. Model supply chain. 3. Training security. 4. Deployment security. 5. Inference monitoring. 6. Incident response. The ordering reflects the artifact's lifecycle: the data is secured, then the model dependency is verified, then the training run is secured, then the harness is deployed, then the running system is monitored, then incidents feed back into the earlier stages."	"b14::lifecycle::stages"
"Why does MLSecOps as a discipline exist — what gap does it fill in the course?"	"The course has taught AI security in pieces (C1: harness engineering; C2B: attacks on the harness; C3: fine-tuning). The pieces are complete but the lifecycle view is missing — the naming, ordering, gates, toolchain, and operating cadence that turn pieces into a discipline. A team that learned the pieces 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."	"b14::rationale::discipline"
"Map the six MLSecOps stages to existing course content."	"Stage 1 data security → C3 Pillar 1 + C2B B3. Stage 2 model supply chain → C2B B4/SDD-B07 + B13 representation attacks. Stage 3 training security → C3 Pillars 2–5. Stage 4 deployment security → C2B B7 + C1 Module 5. Stage 5 inference monitoring → C2B B8 + C1 Module 10. Stage 6 incident response → C2B Capstone 2. Every stage maps to already-taught content — MLSecOps adds the naming and ordering."	"b14::lifecycle::mapping"
"What is the security concern and the canonical failure mode of Stage 1 (data security)?"	"Concern: the model learns from data; if the data is poisoned, tampered with, or untrusted, the model learns the attacker's intent. Failure mode: data poisoning — crafted examples that produce a backdoor (trigger-activated) or a bias (systematic favoritism). The hardest variant is the clean-label attack, where every injected example is correctly labeled, making the poisoning invisible to label inspection. The structural variant is the data-supply-chain attack: the dataset is sourced from a third party (Common Crawl, Hugging Face) and the third party is compromised."	"b14::stage1::data_security"
"What is the clean-label attack and why is it harder to detect than ordinary data poisoning?"	"In a clean-label attack, every injected example is correctly labeled — the example appears in the correct class, with the correct ground-truth label — but the FEATURES are crafted to produce a backdoor. Because the labels are correct, label-inspection defenses (which flag mismatched label/feature pairs) do not flag the injected examples. The poisoning is invisible to the most obvious defense. Detection requires statistical anomaly detection on the feature distribution, not label inspection."	"b14::stage1::clean_label"
"What is the security concern and failure mode of Stage 2 (model supply chain)?"	"Concern: most teams do not train from scratch — they download a base model and fine-tune. The base model is a supply-chain dependency with the same risks as any third-party software. Failure modes: the trojaned base model (behaves normally except on a trigger), the typosquatted model (close-name impersonation), the evil-twin model (valid signature from a malicious publisher — signature verifies identity, not benignity, the same ASI08 pattern at the model layer), and the representation-level backdoor (encoded in the model's internal geometry, invisible to input-layer inspection)."	"b14::stage2::supply_chain"
"What is the model SBOM and how does it relate to the agent SBOM from SDD-B07?"	"The model SBOM is the Software Bill of Materials for a model — an enumeration of its lineage (base model, dataset, fine-tuning run, evaluation results), signed by the producer and verified by the consumer. It generalizes from the agent SBOM in SDD-B07: 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 identical — enumerate dependencies, sign the enumeration, verify the signature — applied at three layers of granularity."	"b14::stage2::model_sbom"
"What is a trojaned base model and why is it a supply-chain threat rather than a training threat?"	"A trojaned base model behaves normally on standard inputs but produces attacker-chosen outputs when a specific trigger appears. It is a supply-chain threat because the trojan was injected by whoever produced the base model — BEFORE your fine-tuning run. Your training run inherits the trojan because fine-tuning does not typically purge backdoors in the base model's representations. You cannot fix it by training harder; you must detect it at the supply-chain gate (model scan) and reject the base model."	"b14::stage2::trojan"
"Why does a valid publisher signature NOT guarantee a model is safe to deploy?"	"A signature verifies the publisher's identity — that the artifact came from the entity claiming to produce it. It does NOT verify the artifact's benignity. A malicious publisher can produce a signed trojaned model. A typosquatted model can have a valid signature from an attacker-controlled publisher that resembles a legitimate one. The signature answers 'who produced this,' not 'is this safe.' This is the same ASI08 supply-chain pattern from SDD-B01, now at the model layer. The cure is the model scan in addition to the signature check."	"b14::stage2::signature_vs_benignity"
"What are the two concerns of Stage 3 (training security)?"	"(1) 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. Controls: access-controlled infrastructure, hashed-and-verified data, version-controlled hyperparameters, reproducibility. (2) Adversarial robustness — the model must resist the threats it will face in deployment. Controls: adversarial training (corpus includes adversarial examples) and red-team evaluation before deployment. A model that exits training without passing the red-team eval does not deploy."	"b14::stage3::training"
"What is the failure mode of Stage 4 (deployment security) and which C1/C2B content prevents it?"	"Failure mode: the un-harnessed model — a model served without input validation, tool contracts, sandbox, or output handling, directly exposed to user input. The secondary failure is the misconfigured harness (controls present but wrong — taint threshold too loose, sandbox allowlist too broad, output handler sanitizes for the wrong consumer). The control is the C1 five-layer harness (input validation, tool contracts, sandbox, output handling, observability) layered with the C2B defenses (taint gates, instruction hierarchies, capability enumeration, signed manifests, circuit breakers). Maps to C2B B7 + C1 Module 5."	"b14::stage4::deployment"
"What is the load-bearing claim about Stage 5 (inference monitoring) and what four runtime threats does it address?"	"Load-bearing claim: no model is safe at rest; safety is a property of the running system. Four runtime threats: (1) the deployed attack (prompt injection, goal hijack, tool abuse — the C2B surface, now observed live); (2) drift (input distribution shifts from training, behavior degrades); (3) the slow compromise (an attacker probes over weeks, building toward a chain no single-turn monitor catches); (4) the silent failure (plausible-but-wrong outputs structurally valid enough to escape any output monitor). Control: the observability substrate from B8 + C1 Module 10."	"b14::stage5::monitoring"
"What is drift and why does it require runtime monitoring that DevSecOps never needed?"	"Drift is the statistical shift of the model's input distribution away from its training baseline as the world changes. Software behavior is fixed once deployed (modulo configuration); a model's behavior depends on its inputs, and its inputs drift. The model's accuracy, calibration, and safety properties all degrade as drift accumulates. Drift detection — statistical monitoring of the input distribution with alerts when drift exceeds a threshold — is a runtime concern that has no software analogue because software does not have this property. This is one of the five new MLSecOps primitives."	"b14::stage5::drift"
"What are the four failure modes of Stage 6 (incident response) and what control addresses each?"	"(1) Undetected incident — attack succeeded, no monitor flagged it; control: the inference-monitoring layer that should have caught it. (2) Slow containment — detected but no runbook; control: incident runbooks per class (prompt-injection breach, data exfiltration, supply-chain compromise, drift beyond threshold), each with containment procedure, rollback path, communication plan. (3) Repeated incident — contained but root cause not fed back; control: root-cause mapping to the failed stage. (4) Un-attributed incident — contained but wrong stage blamed; control: lifecycle-stage attribution discipline. The Capstone 2 engagement is the rehearsal."	"b14::stage6::incident_response"
"What is the feedback loop and why is it what makes MLSecOps a lifecycle rather than a checklist?"	"The feedback loop is the practice of attributing every incident to the lifecycle stage where the control failed (was it data-security, model-supply-chain, training-robustness, deployment-configuration, or monitoring?) and applying the fix to that stage's gate. Without the feedback loop, the same attack succeeds again next quarter — the incident was contained but the lifecycle was not improved. The feedback loop is what converts a sequence of one-time checks into a self-improving lifecycle. The Capstone 2 engagement is the rehearsal of the full loop."	"b14::stage6::feedback_loop"
"Name the five DevSecOps primitives that TRANSFER to MLSecOps."	"(1) SBOM — software SBOM becomes model SBOM (enumerate dependencies, sign, verify). (2) CI/CD gates — code gates become model gates (artifact does not proceed without checks passing). (3) Signed artifacts — image/binary signatures become model/dataset signatures (.safetensors supports this). (4) Secrets management — vault-based, never in code (plus the new concern that the model may have memorized secrets). (5) Least privilege — services get minimum permissions; so do training pipelines, model servers, inference endpoints. These transfer because the underlying problem is the same: an artifact is produced, transported, verified, deployed, operated."	"b14::devsecops::transfers"
"Name the five primitives that are NEW in MLSecOps — no DevSecOps analogue."	"(1) Model scanning — binary scanners do not understand model files; a backdoor can be encoded in the statistical structure of millions of weights. (2) Adversarial robustness — a model has a continuous robustness surface with no clean safe/unsafe boundary, unlike software's bug/no-bug. (3) Drift detection — model behavior depends on inputs, inputs drift, no software analogue. (4) Prompt-injection monitoring — the LLM-specific natural-language injection surface. (5) Representation-layer analysis — the model's internal geometry as a security surface (backdoors encoded in representation clusters, memorized secrets detected by probing activations). All five arise from properties of ML that software does not have."	"b14::devsecops::new"
"Why is the anti-pattern 'we have a CI/CD pipeline, so we are doing MLSecOps' dangerous, and what is the cure?"	"The pipeline covers the transferring primitives (build, sign, deploy, scan-for-binary-vulnerabilities) but not the five new ones (model scan, robustness eval, drift detection, injection monitoring, representation analysis). The model deploys without any ML-specific gate. The cure is NOT to abandon DevSecOps (the transferring primitives are necessary); the cure is to EXTEND — take the DevSecOps pipeline as the substrate, add the five ML-specific gates on top, one per new concern. The DevSecOps pipeline is the substrate, not the complete solution."	"b14::antipattern::devsecops_only"
"What is the deployment gate and what four checks must pass before a model reaches production?"	"The deployment gate is the single most important MLSecOps practice: a model does not reach production until four composed checks pass, and the evidence is recorded in the model SBOM. (1) Data security: corpus hash matches the signed manifest; poisoning detection below threshold. (2) Model supply chain: ModelScan passed; base model SBOM verified; publisher signature valid. (3) Training security: red-team eval above deployment threshold; no critical adversarial perturbations. (4) Deployment security: harness checklist (C1 five layers, C2B defenses) complete and passing. Fail any one, the model does not deploy. Pass all four, the model deploys with SBOM as the certificate."	"b14::gate::deployment"
"What is ModelScan and at which lifecycle stage does it belong?"	"ModelScan is ProtectAI's open-source 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 that execute arbitrary code on load (the classic .pickle deserialization attack), suspicious tensor names, anomalous weight distributions, and signatures of known trojans. It belongs in the MODEL-SUPPLY-CHAIN stage as a deployment gate: a model does not proceed to deployment until ModelScan has passed. The lab implements a minimal ModelScan-style scanner."	"b14::tools::modelscan"
"How do the four MLSecOps tool vendors — ModelScan/ProtectAI, HiddenLayer, Robust Intelligence — differ in lifecycle coverage?"	"ModelScan (ProtectAI): model-supply-chain stage; file scanner. ProtectAI broader suite: training + deployment + monitoring (ray-based robustness, injection detection, model monitor) — most complete single vendor. HiddenLayer: inference-monitoring + training-security; runtime monitors for adversarial inputs, drift, extraction attempts; training product detects poisoning — strongest when inference monitoring is the priority. Robust Intelligence (Cisco): continuous-validation across training, deployment, monitoring; the distinguishing property is CONTINUOUS adversarial testing on a cadence, not just at deployment — catches drift-induced vulnerabilities that emerge post-deployment. No single vendor covers all six stages; integrate by stage."	"b14::tools::landscape"
"Why is .safetensors the right format for the model-scan lab, and what does the scan focus on?"	".safetensors is the modern, safe model-serialization format — it does not execute arbitrary code on load, unlike .pickle (the classic deserialization attack). Because deserialization is safe, the scan focuses on the CONTENT of the tensors rather than the deserialization risk. The lab implements three checks: (1) tensor-name pattern matching against known-trojan conventions; (2) weight-distribution anomaly detection (mean, variance, extreme values) against known-backdoor signatures; (3) metadata provenance verification. The scanner produces a deployment-gate report — PASS (deploy) or FAIL (do not deploy) with reasons."	"b14::lab::safetensors"
"Why does no single MLSecOps vendor cover the lifecycle, and what is the integration principle?"	"No single vendor covers all six stages because each vendor's product was built around a specific threat or stage: ModelScan around the file-scan gate, HiddenLayer around runtime monitoring, Robust Intelligence around continuous adversarial validation. The boundaries (data security, incident response) are poorly covered by every vendor. The integration principle: each tool produces evidence (a scan result, an evaluation score, a monitoring alert), and the evidence is the input to the next stage's gate. The MODEL SBOM carries the evidence forward — it records that data passed, scan passed, eval passed, harness passed — so the deployment gate can verify the full chain of evidence rather than re-checking each stage."	"b14::tools::integration"
"What is the anti-pattern 'treating the model as a black box in production' and what is the cure?"	"A DevSecOps monitoring stack watches infrastructure metrics — CPU, memory, latency, request rate. A model under prompt-injection attack, drifting, or producing plausible-but-wrong outputs looks healthy to every infrastructure monitor, because the attack is in the model's behavior, not the infrastructure's load. The cure is to add model-behavior monitors to the production stack: drift detection (input distribution vs training baseline), injection detection (score inputs for injection signatures), output-harm scoring (flag outputs for harm indicators), and confidence-calibration monitoring. Infrastructure monitoring is necessary but not sufficient — the model-behavior layer is what catches ML-specific attacks."	"b14::antipattern::black_box"
"What is the difference between the model SBOM as an enumeration and the model SBOM as a certificate?"	"As an enumeration, the model SBOM lists the model's lineage — base model, dataset, fine-tuning run, evaluation results — signed by the producer and verified by the consumer. As a certificate, the model SBOM is the deployment gate's evidence artifact: it records that the data security check passed, the model scan passed, the red-team eval scored above threshold, and the harness checklist passed. The deployment gate verifies the full chain of evidence carried in the SBOM rather than re-running every check. The SBOM is both the manifest (what is in this model) and the attestation (why this model is allowed to deploy)."	"b14::gate::sbom_certificate"
"Why is the model-supply-chain stage enforceable as a deployment gate in a way that, say, the inference-monitoring stage is not?"	"The model-supply-chain stage operates on a static artifact (the model file) at a discrete point in time (before deployment). The artifact can be scanned, hashed, verified, and signed, and the scan is deterministic — the same file produces the same result. The inference-monitoring stage operates on a running system whose inputs are unbounded and whose behavior is probabilistic; the checks are statistical (drift scores, injection scores, harm scores) rather than binary, and they never terminate. The supply-chain gate is a pass/fail at a moment; the monitoring gate is a continuous score that can fire alerts but rarely produces a clean pass. This is why the deployment gate composes four checks but the monitoring stage runs continuously."	"b14::gate::static_vs_runtime"