Security Pitfalls in Data Science Apps: Auth, Secrets, Supply Chain, and Safer Defaults

[0:00]Brian: Welcome to the Data Science Stack podcast, where we dig into the real stories behind building, deploying, and protecting modern data products. I'm your host, Alex Tran. Today, we're focusing on a topic that doesn't get enough attention: security pitfalls in data science apps, from authentication to secrets management, supply chain risks, and the hidden dangers of unsafe defaults.

[1:15]Brian: Joining me is Dr. Priya Chandra, Lead Data Security Architect at SecureAI Labs. Priya, welcome! Can you start by telling us a bit about your journey—and why security in data science became your specialty?

[1:45]Dr. Priya Chandra: Thanks, Alex. It's great to be here. My background is in both machine learning and security engineering, and over the years, I've seen firsthand how data science teams, in their drive to innovate, can sometimes overlook some basic—but critical—security practices. What drew me in was realizing how often small oversights, like a misplaced credential or an unchecked dependency, could have outsized consequences.

[2:45]Brian: I love that. So, let’s set the stage: why do you think security is so often missed or left as an afterthought in data science projects?

[3:10]Dr. Priya Chandra: Honestly, I think it's a mix of cultural and technical reasons. Data scientists are incentivized to deliver insights and models fast, not to architect secure systems. Many came up in academia, where openness is prized and security isn’t emphasized. And then, from a tooling perspective, a lot of the frameworks and environments make it just a bit too easy to cut corners.

[4:00]Brian: That totally resonates. I remember the first time I spun up a Jupyter notebook in the cloud—no password, public URL. It felt magical, but also a bit terrifying in hindsight.

[4:30]Dr. Priya Chandra: Exactly! And that’s a great example. The stakes are high because these apps often have access to sensitive data, internal APIs, or critical business logic. If you leave the door open, someone’s going to walk in eventually.

[5:00]Brian: Let’s get concrete. Can you walk us through a real-world scenario where a small oversight led to a big security problem?

[5:25]Dr. Priya Chandra: Sure. One that sticks with me: a research team was sharing notebooks via a public cloud instance. They thought, 'We’ll just use it for a week.' But they left the default config—no password, open port. Within hours, a bot found it, ran cryptomining scripts, and also scraped some internal API keys from their environment variables. It was a mess to clean up.

[6:15]Brian: That’s wild. So, not only did they get hit with cryptomining, but also potential data exposure.

[6:30]Dr. Priya Chandra: Right. And it’s surprisingly common. Attackers are constantly scanning for open notebook servers, unsecured S3 buckets, and similar misconfigurations.

[7:05]Brian: Let’s pause and define authentication and authorization in the context of data science apps. How are they different from, say, a typical web app?

[7:30]Dr. Priya Chandra: Great question. Authentication is proving you are who you say you are—think passwords, tokens, or certificates. Authorization is what you’re allowed to do. In data science, we often have APIs, batch jobs, or notebook servers, and the lines blur. For example, a model-serving API might be exposed to the internet, but without proper authentication, anyone can send requests—or worse, upload malicious payloads.

[8:20]Brian: And sometimes the same user might need different permissions depending on the context, right? Like, a data scientist running an experiment versus a production inference job.

[8:40]Dr. Priya Chandra: Exactly. And this is where it gets tricky. Teams sometimes hard-code tokens or use overly broad permissions just to get things working, then forget to tighten them up later.

[9:05]Brian: Can you share a story where authentication—or the lack of it—caused problems?

[9:30]Dr. Priya Chandra: Absolutely. A client built a custom model API for internal use, but they skipped authentication for convenience, relying on a firewall. When that firewall rule changed during a network migration, the API was suddenly exposed. It took days before anyone noticed strange traffic patterns.

[10:05]Brian: So, the lesson is: don’t trust just the perimeter defenses.

[10:15]Dr. Priya Chandra: Right. Defense in depth. Always have authentication at the app level, not just the network layer.

[10:20]Brian: Let’s dig into that notebook example from earlier. Walk us through what made it so vulnerable.

[10:40]Dr. Priya Chandra: Sure. Jupyter notebooks, by default, are designed for rapid local development. But when you run them in the cloud, the defaults can be dangerous: no password, all network interfaces open, no HTTPS. Unless you explicitly lock them down, you’re basically inviting the internet to your workspace.

[11:15]Brian: And because notebooks are interactive, attackers can run arbitrary code if they get in.

[11:30]Dr. Priya Chandra: Exactly. And often, those environments have secrets and tokens loaded for convenience. So, it’s not just code execution—it’s access escalation.

[11:50]Brian: So, what should teams do by default when deploying notebooks or similar tools in the cloud?

[12:05]Dr. Priya Chandra: At a minimum: set a strong password or token, bind to localhost or use a VPN, and always use HTTPS. Ideally, put notebook servers behind an authentication proxy and restrict network access as much as possible.

[13:15]Brian: Let’s shift to authorization for a second. I’ve seen teams struggle with getting roles and permissions right for ML APIs. What are the common pitfalls?

[13:40]Dr. Priya Chandra: One big pitfall is granting 'admin' or 'superuser' permissions to every service or user, just because it’s easier. Another is failing to distinguish between read and write access, or between training, validation, and inference contexts. The more granular you can get, the better your security posture.

[14:10]Brian: But that granularity can be a pain to manage, especially as teams grow.

[14:25]Dr. Priya Chandra: It can. But automation helps—a good identity and access management system can make role-based access easier to scale. And it pays off the first time something goes wrong.

[14:55]Brian: What about third-party tools? A lot of teams integrate SaaS solutions or cloud services. Any gotchas there?

[15:15]Dr. Priya Chandra: Definitely. Sometimes, service accounts or integrations are granted broad permissions by default. Always follow the principle of least privilege—only give the minimum access needed, and rotate credentials regularly.

[15:50]Brian: Let’s talk about secrets management. What kinds of secrets are we actually talking about in data science apps?

[16:10]Dr. Priya Chandra: It can be anything: API keys for external services, database passwords, cloud tokens, encryption keys, even credentials for message queues or storage buckets. Any piece of information that, if leaked, would give someone unauthorized access.

[16:35]Brian: And how do these secrets end up leaking in practice?

[16:50]Dr. Priya Chandra: So many ways! Hard-coded in notebooks or scripts, accidentally committed to version control, left in shared Slack channels, included in logs or error messages, or even baked into serialized model artifacts.

[17:20]Brian: I have to admit, I’ve committed an API key to Git before. Caught it in time, but it was a wake-up call.

[17:40]Dr. Priya Chandra: A lot of people have. That’s why tools that scan for secrets in code are so useful—but they’re not perfect. Prevention is better than cure.

[18:00]Brian: Is there a safe way to use secrets in notebooks or scripts, especially when collaborating?

[18:15]Dr. Priya Chandra: Best practice is to never store secrets in code. Use environment variables, secret managers, or vaults. For collaboration, share secrets via secure channels, and prefer role-based access where possible. And always rotate keys when someone leaves the team.

[18:30]Brian: Can you give an example where a secret leak led to a major incident?

[18:50]Dr. Priya Chandra: Sure. At one company, a database password was accidentally shared in a Slack channel that included external contractors. Within a week, someone used it to access sensitive training data. The team had to rotate all credentials and do a full audit.

[19:30]Brian: Wow. And that’s not a hypothetical—that’s a real breach.

[19:40]Dr. Priya Chandra: Absolutely. And it’s becoming more common as teams grow and collaborate across time zones and organizations.

[20:00]Brian: Are there other less obvious channels where secrets leak?

[20:15]Dr. Priya Chandra: Yes. Logs are a big one—sometimes secrets get printed during debugging. Also, serialized models—if you pickle a pipeline that includes credentials, they can end up in the artifact.

[20:40]Brian: So, scanning logs and artifacts regularly is a must.

[20:50]Dr. Priya Chandra: Yes. And ideally, have automated checks in your CI/CD pipeline to catch these issues before anything gets shipped.

[21:00]Brian: For teams just starting to formalize their secrets management, where’s the best place to begin?

[21:20]Dr. Priya Chandra: Start with inventory: know what secrets you have and where they’re stored. Then move to environment variables, and graduate to using a secrets manager or vault as soon as possible. Educate your team on what not to do, and automate reminders to rotate credentials.

[21:50]Brian: Should every data science team be using a secrets manager, even for small projects?

[22:05]Dr. Priya Chandra: In an ideal world, yes. But at minimum, don’t store secrets in code or notebooks. Even for side projects, bad habits can carry over.

[23:30]Brian: Let’s pivot to supply chain risks. For listeners who haven’t heard this term, what do we mean by supply chain in the context of data science?

[23:50]Dr. Priya Chandra: It’s the set of dependencies your code relies on—open-source libraries, packages, containers, even pre-trained models. If any link in that chain is compromised, your app can be too.

[24:15]Brian: And in data science, the dependency trees can be enormous. One requirements.txt file can pull in hundreds of packages.

[24:35]Dr. Priya Chandra: Exactly. And because data science moves fast, people often install packages ad hoc, sometimes from less reputable sources. Attackers know this, and they sometimes publish malicious packages with names similar to popular libraries—a technique called typosquatting.

[25:10]Brian: So, what’s a practical example of a supply chain compromise in a data science project?

[25:30]Dr. Priya Chandra: A memorable case: a team added a new visualization package to their pipeline without proper vetting. The package actually included malicious code that exfiltrated environment variables on import—so secrets, tokens, all gone. It was only caught months later during a security audit.

[26:00]Brian: Yikes. And I imagine this isn’t just about open-source. Even pre-trained models or vendor containers can be vectors.

[26:20]Dr. Priya Chandra: Absolutely. Always verify sources, use hash-based package locks, and audit dependencies regularly. And don’t blindly trust containers from public registries.

[27:00]Brian: Let's pause there. We’ve covered a lot—authentication, secrets, and supply chain risks, with some pretty eye-opening stories. After the break, we’ll dive into the hidden dangers of default settings, and how to actually build safer data science workflows. Priya, stick with us?

[27:20]Dr. Priya Chandra: Absolutely. Looking forward to it.

[27:30]Brian: Stay tuned, everyone. We’ll be back in just a moment.

[27:30]Brian: Alright, welcome back! So far, we’ve touched on the basics of security pitfalls in data science applications, especially around authentication and secrets management. Let’s zoom out and dig into some real-world stories and deeper nuances, especially around supply chain and those so-called 'safe defaults.' Sound good?

[27:39]Dr. Priya Chandra: Absolutely. I think this is where things often go from theory to reality. The supply chain angle, in particular, has gotten a lot hairier for data science teams lately.

[27:48]Brian: Let’s start there. When we say 'supply chain' in this context, what are we talking about? Is it just dependencies, or is it broader?

[27:59]Dr. Priya Chandra: Great question. For data science, supply chain risks cover everything you bring into your environment: open-source libraries, pre-trained models, data connectors, sometimes even the Docker images used for deployment. Each is a potential attack vector.

[28:09]Brian: So if I pip install a package that’s been compromised, my whole app could be at risk—right?

[28:18]Dr. Priya Chandra: Exactly. In fact, there was a recent case where a popular data visualization library got hijacked. Attackers slipped in a malicious update that exfiltrated environment variables, including API keys. Teams didn’t catch it for weeks.

[28:26]Brian: Oof. And I bet a lot of teams still don’t pin their dependencies or verify them.

[28:37]Dr. Priya Chandra: That’s right. And it’s not just Python packages—think about pre-trained models. I know of a team that pulled a sentiment analysis model from a public repo. Turned out, the model had been poisoned to misclassify certain phrases. They only noticed after a customer complained about bizarre results.

[28:47]Brian: Wow, so even the 'data' in data science apps can be a supply chain risk. What can teams do to guard against this?

[28:59]Dr. Priya Chandra: A few things. First, lock your dependencies with hashes—so only specific versions get installed. Second, use internal registries or vetted sources for models and libraries. Third, scan everything—there are tools that check for known vulnerabilities or unexpected changes.

[29:08]Brian: Can you give an example of a tool or process that’s helped you catch something before it shipped?

[29:19]Dr. Priya Chandra: Sure. On one project, we used a dependency scanner as part of our CI pipeline. It flagged an obscure package that had been deprecated and later picked up by someone else—who added crypto-mining code. Saved us some serious headaches.

[29:30]Brian: That’s wild. Let’s pivot a bit—how do these supply chain risks interact with secrets management? Like, if a dependency is compromised, could it expose my config files or environment variables?

[29:42]Dr. Priya Chandra: Absolutely. If a malicious package gets code execution, it can grab any secrets your app can access—API keys, DB credentials, whatever. That’s why it’s so important to use the principle of least privilege and keep secrets out of your codebase.

[29:52]Brian: That brings us to another pitfall—safe defaults. What does that even mean in a data science context?

[30:05]Dr. Priya Chandra: It means that, out of the box, your app or library should do the secure thing—even if the developer forgets to configure it. For example, a model server should require authentication by default, not just for ‘production’ but for every environment.

[30:15]Brian: I’ve seen a lot of cloud notebooks spinning up with no password or token protection. Easy for demos, but dangerous in practice.

[30:27]Dr. Priya Chandra: Exactly. Another example: default file permissions. Some data science tools default to world-readable output files, which can expose sensitive data. Unless you’re careful, things end up accessible to anyone on the server.

[30:36]Brian: Let’s dig into a case study. Can you share a story where unsafe defaults led to a real incident?

[30:50]Dr. Priya Chandra: Sure. A team was deploying a Jupyter-based analytics portal internally. The default config had token auth disabled. Someone found the endpoint, and because the server ran with elevated permissions, they could access internal dashboards and even production databases. The breach went unnoticed until an audit months later.

[31:00]Brian: That’s a nightmare scenario. Was it hard to fix after the fact?

[31:10]Dr. Priya Chandra: The technical fix was easy—just flip a config switch. But the trust damage and the need to rotate secrets and audit logs took weeks. And they had to retrain the team on security hygiene.

[31:18]Brian: So, if you were building a data science product today, what’s your go-to checklist for safe defaults?

[31:29]Dr. Priya Chandra: Require authentication everywhere, use secure protocols by default, minimize open ports, sensible file permissions, and never log secrets. Also, make it easy for users to rotate credentials.

[31:36]Brian: Before we go further, let’s do a quick rapid-fire round. Ready?

[31:38]Dr. Priya Chandra: Hit me!

[31:40]Brian: One: Biggest overlooked security risk in data science apps?

[31:43]Dr. Priya Chandra: Misconfigured access controls—hands down.

[31:45]Brian: Two: Secrets in code—ever okay?

[31:47]Dr. Priya Chandra: Never. Not even for a quick test.

[31:49]Brian: Three: Model files—store in git?

[31:51]Dr. Priya Chandra: Nope. Use dedicated artifact storage.

[31:53]Brian: Four: Open-source libraries—trust or verify?

[31:55]Dr. Priya Chandra: Always verify, then monitor.

[31:57]Brian: Five: Default passwords—change on first run?

[31:59]Dr. Priya Chandra: Absolutely. And force users to do it.

[32:01]Brian: Six: Cloud notebook exposed to the internet—what do you do?

[32:03]Dr. Priya Chandra: Lock it down or shut it down.

[32:05]Brian: Seven: What’s the best way to audit a legacy data science app for security holes?

[32:09]Dr. Priya Chandra: Start with threat modeling, review dependencies, trace data flows, scan for hardcoded secrets, and check access logs.

[32:11]Brian: Eight: How often should you rotate API keys?

[32:14]Dr. Priya Chandra: At least quarterly, but immediately after any incident.

[32:18]Brian: Nice! Let’s shift to another mini case study. Any stories where people thought they were secure but missed a subtle risk?

[32:32]Dr. Priya Chandra: Yes, actually. One team used environment variables for their secrets, which is great. But then they enabled debug logging in production. Debug logs got pushed to a centralized log aggregator—and those logs accidentally included full environment dumps. So, all secrets were exposed in logs.

[32:36]Brian: Wow. So even good practices can backfire if you’re not careful.

[32:41]Dr. Priya Chandra: Exactly. Security is holistic. You can lock down everything else, but one bad log line can unravel it all.

[32:47]Brian: How would you recommend teams catch that kind of mistake before it hits production?

[32:58]Dr. Priya Chandra: Automated checks in your CI pipeline can scan logs for sensitive info. Some teams even maintain lists of forbidden strings, like 'SECRET' or 'TOKEN', and block deploys if those show up in logs.

[33:09]Brian: It sounds like a lot of these risks get magnified at scale. When you’re running a small prototype, it’s easy to skip steps. But in real-world production, you can’t cut corners.

[33:17]Dr. Priya Chandra: That’s right. Early shortcuts become legacy pain. I always say: bake security in as soon as you write code, not after the fact.

[33:25]Brian: Let’s touch on third-party services. A lot of data science apps now depend on external APIs—what’s the best way to secure those connections?

[33:35]Dr. Priya Chandra: Use least-privilege API keys, never embed them in client-side code, and always use encrypted channels. And if possible, set up IP whitelisting and usage limits on those keys.

[33:41]Brian: Have you seen anyone get burned by not doing that?

[33:53]Dr. Priya Chandra: Yes—a team accidentally committed a privileged analytics API key to a public repo. Within hours, someone started racking up massive usage bills. They had to rotate keys and explain it to finance.

[34:03]Brian: Let’s talk team culture. How do you get data scientists, who might not be security experts, to care about these risks?

[34:16]Dr. Priya Chandra: Make security part of the workflow, not a separate checklist. For example, build templates with secure defaults, share post-mortems without blame, and keep security training practical. If people see how an incident affects their own work, it sticks.

[34:25]Brian: Have you seen any cultural shifts or small wins from doing that?

[34:36]Dr. Priya Chandra: Definitely. I’ve seen teams make ‘security champions’—volunteers who bridge the gap between data science and security. Even just having regular lunch-and-learns on recent incidents can raise everyone’s awareness.

[34:45]Brian: Let’s get really practical. If someone’s listening and thinking, 'I have no idea if my data science project is secure'—where should they start?

[34:56]Dr. Priya Chandra: Start small: audit your secrets and access controls. Check who can access your data, and what keys you’re using. Then, look at dependencies—are they pinned, are they safe? Finally, scan your logs for sensitive info.

[35:07]Brian: Let’s do one more mini case study before we wrap up. Any example where a team did everything right—except for one overlooked step?

[35:22]Dr. Priya Chandra: Sure. A team built a great pipeline, locked down secrets, pinned dependencies, and used network controls. But they forgot to set strict permissions on their S3 buckets. A researcher uploaded a sensitive dataset, and the bucket was inadvertently public. They caught it during a routine audit, but it was a close call.

[35:29]Brian: So the lesson is: never assume cloud defaults are secure.

[35:34]Dr. Priya Chandra: Exactly. Always verify your cloud resource settings, and automate checks if you can.

[35:41]Brian: Let’s start wrapping up. We’ll do an implementation checklist—can you walk us through a step-by-step on how to secure a typical data science app?

[35:45]Dr. Priya Chandra: Absolutely. Here’s a practical checklist:

[35:49]Dr. Priya Chandra: One: Inventory all secrets—find where they live and who can access them.

[35:53]Dr. Priya Chandra: Two: Move secrets to a vault or secure environment variables—not in code or notebooks.

[35:57]Dr. Priya Chandra: Three: Pin and hash dependencies—use a lock file and scan regularly.

[36:01]Dr. Priya Chandra: Four: Audit data flows—map out what data is moving where and who can touch it.

[36:06]Dr. Priya Chandra: Five: Enforce authentication and secure protocols everywhere—no open or default endpoints.

[36:11]Dr. Priya Chandra: Six: Check cloud resources—storage buckets, databases, VMs. Make sure permissions are tight.

[36:15]Dr. Priya Chandra: Seven: Review logging—make sure no sensitive info is ever written to logs.

[36:19]Dr. Priya Chandra: Eight: Rotate keys and credentials on a schedule and after any incident.

[36:23]Dr. Priya Chandra: Nine: Train your team—use real incidents and make security part of onboarding.

[36:29]Brian: That’s fantastic. Super actionable. Anything you’d add for teams that already have legacy systems?

[36:37]Dr. Priya Chandra: Start by threat modeling—identify your crown jewels and biggest risks. Then, prioritize fixes that have the biggest impact: secrets, access, and public exposures.

[36:44]Brian: If someone’s facing resistance from their team, what’s the single best argument for taking security seriously?

[36:52]Dr. Priya Chandra: Simple: Security failures cost trust, time, and money. A single mistake can undo years of work. Prevention is always cheaper than the cure.

[37:00]Brian: Couldn’t agree more. Any final thoughts or resources you’d recommend for folks wanting to learn more?

[37:09]Dr. Priya Chandra: Yeah, for sure. There are some great open-source security checklists tailored for data science and ML. Also, follow security researchers and data science blogs—real-world stories are the best teachers.

[37:16]Brian: Awesome. Before we let you go, let’s quickly recap our final checklist for anyone listening:

[37:19]Brian: Inventory and secure all secrets.

[37:22]Brian: Pin dependencies and scan for vulnerabilities.

[37:24]Brian: Audit data flows and access controls.

[37:26]Brian: Lock down cloud resources.

[37:28]Brian: Monitor logs and rotate credentials.

[37:30]Brian: And finally, never rely on safe defaults—verify everything.

[37:33]Dr. Priya Chandra: Exactly. Security isn’t a one-time fix—it’s a habit.

[37:38]Brian: Thank you so much for joining us and sharing these insights. This has been a super practical, eye-opening conversation.

[37:42]Dr. Priya Chandra: Thanks for having me. Hope it helps folks build safer data science products!

[37:48]Brian: And thanks to everyone for tuning in. If you found this helpful, please share it with your team, subscribe, and let us know what topics you want next on Softaims. Stay secure, and see you next time.

[55:00]Brian: This is Softaims, signing off.