Jaron Mink
Arizona State University | Assistant Professor
Jaron Mink is an Assistant Professor in the School of Computing and Augmented Intelligence at Arizona State University. He received his Ph.D. in Computer Science from the University of Illinois at Urbana-Champaign, and his B.Sc. (Magna Cum Laude) from the University of California, Los Angeles.
Jaron investigates computer security threats and focuses on how human factors affect the security of machine learning systems. His work has appeared in top-tier venues (CHI, USENIX Security, IEEE S&P, WWW), has been covered by a variety of news outlets (New Scientist, The Transmitter, The 21st Show), and has been made into educational content (Futurum Careers). Jaron has also served as a consultant for "Partnership on AI", an NGO that fosters the responsible development of AI systems. He is an awardee of the NSF Graduate Research Fellowship Program (GRFP).
## Learning Objectives
After completing this workshop, you will be able to:
- Describe the machine-learning lifecycle, data collection, feature engineering, training, evaluation, deployment, and monitoring, and identify the principal security concern that enters at each stage.
- Explain how MLOps extends software DevOps to manage data and models, and what DevSecOps adds by "shifting security left" and automating checks in the CI/CD pipeline.
- Apply secure coding practices specific to ML: input validation and sanitization, safe data handling, secrets management, and least-privilege access.
- Manage dependency and supply-chain risk with pinned versions and vulnerability scanning (for example pip-audit, Bandit, and Trivy).
- Explain why loading untrusted models is dangerous, how pickle-based formats such as `torch.load` enable arbitrary code execution, and how safer formats such as safetensors mitigate it.
- Recognize the threats that enter through the pipeline, data poisoning, model theft, adversarial examples, and lost artifact provenance, and connect them to reproducibility and integrity.
- Outline the elements of secure deployment, container hardening, authenticated and rate-limited API endpoints, and TLS, and know where the program develops them further.
- Match the major compliance frameworks (GDPR, HIPAA, ISO/IEC 27001, the NIST Cybersecurity Framework, and the NIST AI Risk Management Framework) to the ML concerns each governs.
- Explain, from the guest lecture's research, why known ML defenses are often not implemented, and why closing that gap is organizational as much as technical.
## Theoretical Background
### The Machine-Learning Lifecycle as an Attack Surface
A useful mental model, and the one the guest lecture opens with, is to draw the ML system as a pipeline and then ask where security and privacy problems can occur. In its fullest form the lifecycle runs:
**Data collection and preparation → feature engineering → training → evaluation → deployment → monitoring**, with monitoring feeding back into retraining.
Every stage is a boundary an attacker or an accident can cross. Poisoned or low-quality data enters at collection. Sensitive attributes can leak during feature engineering. Training can be non-reproducible or run on tampered data and dependencies. Evaluation can miss adversarial and edge-case behavior. Deployment exposes endpoints, containers, and model files. Monitoring can fail to notice drift, degradation, or an attack in progress. The central discipline of this workshop is to attach a concrete practice to each of those concerns rather than bolting security on at the end.
| Lifecycle stage | Principal security concern | Practice / tooling |
|---|---|---|
| Data collection & preparation | Poisoned or untrusted data; sensitive-data exposure; weak provenance | Provenance and lineage tracking; data validation; encryption at rest and in transit; access control; zero-trust and least privilege |
| Feature engineering | Leakage of sensitive attributes; unsanitized inputs | Input validation and sanitization; data minimization; remove unnecessary personal data |
| Training | Non-reproducibility; tampered data or dependencies | Pinned dependencies; log parameters, seeds, and data versions; integrity checks; isolated compute; audit logging |
| Evaluation | Blind spots to adversarial and edge behavior | Adversarial and robustness testing; fairness and backdoor checks; signed evaluation reports |
| Deployment | Vulnerable containers; exposed endpoints; unsafe model loads | Image scanning; authentication and authorization; rate limiting; TLS; safe model formats |
| Monitoring | Data drift; silent degradation; live attacks | Drift detection; security monitoring; performance and fairness monitoring; incident response |
### From DevOps to MLOps to DevSecOps
**DevOps** shortened the loop between building software and running it, code moves through build, test, deploy, monitor, and feedback, with as much of that path automated as possible. **MLOps** applies the same operational discipline to machine learning, but the object under management is larger. In software DevOps the versioned artifact is code; in MLOps it is code plus data plus trained models plus configuration, and the system's behavior is data-dependent rather than deterministic. That difference reshapes every operational concern.
| Aspect | Software DevOps | MLOps |
|---|---|---|
| Versioned artifact | Code | Code, data, models, and configuration |
| Testing | Unit and integration tests | Data validation, model tests, bias and robustness checks |
| Behavior | Deterministic | Non-deterministic, data-dependent |
| Monitoring | Error rates, latency, uptime | Model performance, data drift, fairness, plus the above |
| Rollback | Revert to a previous code version | Revert to a previous model or retrain |
**DevSecOps** is the security discipline layered onto this. Its two organizing ideas are to *shift security left*, moving security review, testing, and threat modeling to the earliest stages rather than treating them as a pre-release gate, and to *automate* those checks inside the continuous-integration and continuous-deployment (CI/CD) pipeline so that they run on every change without depending on someone remembering. In an ML pipeline that means dependency scanning and static analysis on every commit, data validation before training, adversarial and fairness tests in the evaluation stage, container image scanning before deployment, and monitoring wired into production from day one.
### Attacking the ML Pipeline
The guest lecture makes the threat model concrete by marking where attacks strike the same pipeline. Two are emblematic. **Poisoned data** is injected at the data-collection stage: by tampering with training data an attacker corrupts the model that is learned from it, potentially planting a backdoor that behaves normally until a trigger appears. **Adversarial examples** strike at deployment: a crafted input causes a trained model to produce an attacker-chosen ("hacked") prediction. Between and around these sit **model theft** (reconstructing or cloning a proprietary model through its API), **data leakage** (recovering sensitive training data from the model), and the loss of **artifact provenance** (not knowing which data, code, and parameters produced a given model, which makes both reproduction and forensic investigation impossible).
The through-line is that pipeline security is not only about defending the final model. Data poisoning is a *data-stage* failure of integrity and provenance; artifact provenance and reproducibility are *training-stage* properties; adversarial robustness is an *evaluation and deployment* property. Securing the pipeline means securing each stage's inputs, outputs, and records, so that the model you deploy is the model you built, trained on the data you trust.
### Secure Coding Practices for Machine Learning
Beneath the lifecycle sit the ordinary, unglamorous coding practices that prevent most real incidents. The following are drawn from the workshop's secure-coding reference and apply directly to ML codebases.
**Input validation and sanitization.** Never trust external input, whether it arrives through an API, a file upload, or a network interface. Before processing a file, check that it exists and is readable, that its type matches what is expected, and that its size is bounded so an oversized input cannot exhaust resources and cause a denial of service. The insecure pattern, opening and processing whatever arrives, lets an attacker supply arbitrary data that crashes the system or drives unexpected behavior; the secure pattern validates first and consistently.
**Safe data handling.** Treat data with the rigor you would apply to cryptographic keys. Encrypt sensitive data at rest and use TLS/HTTPS in transit. Apply access control on the principle of least privilege, and minimize what you collect and retain in the first place, data you never stored cannot leak. Log access to sensitive stores so there is an audit trail for monitoring and forensics, and remove or pseudonymize personal identifiers that the task does not require.
**Secrets management.** Credentials, API keys, and tokens must never be hardcoded in source, where they leak into repository history and become permanently exposed. Keep them external, in environment variables loaded from protected files or, better, in a dedicated secrets vault, and access them through secure configuration.
**Dependency and supply-chain management.** ML projects import large, fast-moving dependency trees, and each dependency is attack surface. Outdated libraries carry known vulnerabilities; compromised packages carry injected code; version drift introduces silent breakage. Pin versions with a lockfile for reproducible, controlled builds; scan regularly for known vulnerabilities with tools such as **pip-audit** (which checks Python dependencies against vulnerability advisories) and **Bandit** (static analysis for common security issues in Python); scan container images and filesystems with **Trivy**; and prune unused dependencies to shrink the surface.
**Untrusted model loads and unsafe deserialization.** This risk is specific to ML and easy to overlook. Many model formats serialize with Python's `pickle`, and `pickle` can execute arbitrary code during deserialization. Because `torch.load` is pickle-based, loading a model checkpoint downloaded from an untrusted source can run attacker-controlled code on your machine, a supply-chain vulnerability disguised as "just loading a model." The mitigation is to avoid deserializing untrusted pickles and to prefer a format that stores only tensor data and cannot execute code, such as **safetensors**. Treat a third-party checkpoint with the same suspicion as a third-party executable.
**Least privilege throughout.** Give every user, service, and process exactly the access it needs and no more, backed by a zero-trust posture that authenticates and authorizes access to data and infrastructure and continuously monitors it. This limits the blast radius when any single component is compromised.
### A Preview of Deployment Security
Deployment turns a model into a running service, and a running service has an operational attack surface. The essentials are container hardening (build minimal Docker images, scan them for vulnerabilities, run as a non-root user, and keep secrets out of the image), secure API endpoints (TLS for all traffic, authentication to establish who is calling, authorization to check they may perform the requested operation, and rate limiting to blunt abuse and brute-force probing), and monitoring wired in from the start to detect anomalies and attacks. These are introduced here so the lifecycle is complete; **Workshop 11** develops secure deployment and operation of AI systems in depth.
### Regulatory and Compliance Frameworks
Security practice does not exist in a legal vacuum. Several frameworks govern how ML systems that handle personal or sensitive data must be built and operated, and increasingly they turn good practice into a requirement.
| Framework | What it governs | Why it matters to ML |
|---|---|---|
| **GDPR** (EU General Data Protection Regulation) | Processing of EU residents' personal data | Requires lawful basis and consent, purpose limitation, data minimization, retention limits, and supports a right to explanation for automated decisions, constraining what data a model may use and demanding that decisions be explainable |
| **HIPAA** (US health-data law) | Protected Health Information (PHI) | Mandates access controls, audit controls, and encryption for any ML system touching patient data, plus agreements binding third-party processors |
| **ISO/IEC 27001** | Information Security Management Systems (ISMS) | A certifiable framework for managing security systematically, security policy, access control, cryptography, incident management, and supplier assurance, applicable to the organization running the ML system |
| **NIST Cybersecurity Framework (CSF)** | General cybersecurity risk management | Its core functions, Identify, Protect, Detect, Respond, Recover (CSF 2.0 adds a sixth, Govern), give a widely adopted structure for organizing the controls above across the ML lifecycle |
| **NIST AI Risk Management Framework (AI RMF)** | Risks specific to AI systems | Provides an AI-specific vocabulary and process (Govern, Map, Measure, Manage) for identifying and mitigating risks such as bias, robustness failures, and misuse, complementing the general-purpose CSF |
These frameworks are the bridge to the next session. **Workshop 10** takes up AI and data governance, regulations, and standards in depth, treating the legal and policy layer as a subject in its own right rather than a checklist appended to engineering.
### The Human Factor: Why Defenses Exist but Are Not Implemented
The guest lecture's distinctive contribution is empirical and human-centered: it studies not the attacks and defenses themselves but the *people* who are supposed to apply them, and it finds a consistent gap between available defenses and deployed ones. Two studies frame it. One examines how security practitioners perceive ML-based tools and finds that ML is adopted mainly *alongside* rule-based systems rather than replacing them, valued for catching novel patterns but held back by false positives and opacity, and that security is often not even a primary consideration in tool choice. The other asks why ML developers do not secure their systems, and locates the barriers at three points along the path from a developer to an active defense.
- **Exposure.** Many practitioners simply are not exposed to adversarial-ML concepts. Data privacy is broadly understood, but model security and privacy are not; some believe security is "not their field" and separate from ML. The knowledge is concentrated in specialized CS courses and is rarely demanded by project requirements, which are functionality-centered and often set by non-technical stakeholders.
- **Assessment.** Even where developers are aware, misconceptions and missing tools prevent accurate risk assessment. Threat models are frequently wrong, so vulnerabilities go unseen, and evaluation stops at accuracy and F1-scores, adversarial and edge-case testing is ad hoc when it happens at all.
- **Implementation.** Organizational structure impedes the last step. Teams are isolated along the pipeline, so responsibility for defense is diffuse, and security teams are further removed still, so the pipeline rarely benefits from their expertise.
The reference reading reaches the same conclusion from the code itself: ML researchers and practitioners continue to use insecure coding practices despite public documentation of the risks and mature, low-friction tooling, largely because they prioritize rapid experimentation and do not see themselves or their projects as targets. The lesson of the workshop is therefore double. The technical practices in the sections above are necessary, but they are not self-executing. Closing the gap between known and applied security requires organizational commitment: making security a stated project requirement, breaking the isolation between ML and security teams, and building the practices into the pipeline so that doing the secure thing is the path of least resistance.
## Hands-on Lab
This workshop has no coding notebook. It shares its recorded lab walkthrough with Workshops 5 and 10.