Data and ML engineers need training on how they handle data, how they obtain models and packages, how they run notebooks and pipelines, and who can reach what. Their work mixes sensitive data, many third party components and loosely governed environments, so general developer training alone leaves gaps.
Why the usual course misses them
Data teams write code, but their habits differ. They work in notebooks, share datasets by copy, install packages quickly to try an idea and download models from public hubs. Security training written for web developers does not mention any of that.
None of this is careless. Exploration is the job. Training should make the safe path as quick as the unsafe one.
Five topics
- Data handling. Know which datasets contain personal or confidential information, where copies live and who can read them. Teach minimisation: use the smallest sample that does the job.
- Access. Notebook servers and storage buckets are often shared widely for convenience. Teach least privilege and how to request access instead of copying credentials.
- Packages. Data projects install many libraries, often unpinned. The OWASP Proactive Controls include Keep your Components Secure, and the same idea applies to every package in an environment.
- Models and data as supply chain. The OWASP Top 10 for LLM Applications 2025 lists Supply Chain and Data and Model Poisoning as separate risks. Teach engineers to ask where a model or dataset came from, who maintains it and how it was checked before use.
- Pipelines and notebooks. Credentials pasted into a notebook cell get saved with the notebook. Teach where credentials should live instead, and how to clear outputs before sharing.
A format that respects their time
| Format | Content |
|---|---|
| 45 minute workshop | Data classification on your own datasets |
| Pairing session | Review one real notebook for credentials and access |
| Checklist | One page for starting a new project |
| Quarterly note | Short update on a recent issue |
Use examples from your own repositories. Data engineers engage when the example is a notebook they recognise.
Questions every project should answer
- What data does it touch, and is any of it sensitive?
- Which external models, datasets and packages does it use?
- Who has access to the environment, and is that still right?
- Where do outputs go, and who can see them?
Making these four questions part of project kickoff teaches more than a slide deck.
What not to promise
Do not tell engineers that a scan makes a model safe. Tools help with packages and known issues, but judgement about data provenance still requires human attention.
Where Safeguard fits
Safeguard provides dependency scanning and SBOM generation for the packages data projects use, plus policies and gates. It does not offer training courses. Check a project with the free scan at gold.safeguard.sh/scan. For related reading, see our guide on notebook and model file safety.
Quick check
Do data scientists need the same secure coding course as developers?
Share the basics, then add a track on data handling, notebooks and model sourcing.
Who owns security for a shared notebook environment?
Name an owner for the platform. Individual users still need to know what not to paste or store there.
Sources
- OWASP Top 10 for LLM Applications 2025: genai.owasp.org/llm-top-10
- OWASP Top 10 Proactive Controls: top10proactive.owasp.org
Last reviewed: 19 October 2026.
