Hidden Traps in Cloud Security: Auth, Secrets, Supply Chain, and Safe Defaults

[0:00]Vlad: Welcome to the show! Today we're diving deep into a topic that's top-of-mind for anyone building or running cloud-native applications: security pitfalls. I'm your host, Sam Lin, and I’m thrilled to be joined by Priya Deshmukh, a cloud security architect at Nimbus Systems. Priya, thanks for joining us.

[0:30]Priya Deshmukh: Thanks, Sam! I'm excited to be here. Cloud security is a passion of mine, especially when it comes to helping teams avoid the mistakes that are easy to make but costly to fix.

[1:00]Vlad: Let’s set the stage. Cloud apps promise amazing flexibility and scale, but the security side can be unexpectedly tricky. Why do you think so many teams still fall into these traps?

[1:30]Priya Deshmukh: Great question. I think part of it is the speed at which cloud projects move. There’s pressure to deliver features fast, and security can feel like it slows things down. Plus, the cloud introduces layers of abstraction—managed services, APIs, third-party components—so it’s easy to miss where the vulnerabilities creep in.

[2:05]Vlad: So it’s not just 'lift and shift'—the risks actually change?

[2:20]Priya Deshmukh: Exactly. Some old risks get amplified, and new ones appear. For example, exposing an S3 bucket to the public internet by accident is a uniquely cloud-age mistake. The tools make it easy to move fast, but the defaults aren’t always safe.

[3:30]Vlad: Before we get into the nitty-gritty, can you tell us a bit about your background and the kinds of cloud security incidents you’ve seen?

[3:50]Priya Deshmukh: Sure! I started out as an application developer, but kept running into security problems—my own and others’. Eventually, that led me into cloud security architecture. I’ve worked with SaaS startups, enterprise migrations, and even regulated industries. I’ve seen everything from accidental credential leaks to full-blown dependency attacks.

[5:00]Vlad: You mentioned 'security pitfalls.' How do you define that, especially in the context of the cloud?

[5:25]Priya Deshmukh: To me, a pitfall is a subtle risk that’s easy to overlook until it bites you. In cloud, that might mean assuming your provider’s defaults are secure enough, or underestimating how a misconfigured OAuth flow can expose user data. It’s those hidden cracks in the foundation.

[7:15]Vlad: Let’s jump into authentication, since it’s often the first line of defense. What’s different—and risky—about authentication in cloud-native apps?

[7:40]Priya Deshmukh: In the cloud, authentication usually means delegating to third-party identity providers or using protocols like OAuth or SAML. That’s powerful, but it adds complexity. If you misconfigure a callback URL or fail to validate tokens properly, someone can hijack sessions or impersonate users.

[9:20]Vlad: I’ve heard of teams getting tripped up by OAuth. Can you walk us through a common mistake there?

[9:45]Priya Deshmukh: Definitely. One classic blunder is leaving the redirect URI too broad or unvalidated. Attackers can craft malicious URLs that trick your app into sending tokens to the wrong place. I once saw a production app accept any redirect URI, which meant anyone could intercept the authorization code.

[10:30]Vlad: Wow. If that happens, what’s the fallout?

[10:50]Priya Deshmukh: Best-case, it’s just a user inconvenience. Worst-case, it’s full account compromise. The attacker can log in as someone else, access sensitive data, or even escalate privileges. And because OAuth is so common, these mistakes can scale across a fleet of apps.

[11:30]Vlad: Let’s pause and define a couple terms. You mentioned redirect URI—what’s that?

[11:45]Priya Deshmukh: Sure. In OAuth, a redirect URI is where the authorization server sends the user and their access token after login. If you don’t tightly control that value, someone can send tokens somewhere malicious instead.

[12:10]Vlad: Got it. Let’s get concrete. Can you share a case where OAuth misconfiguration caused real trouble?

[12:40]Priya Deshmukh: Absolutely. One SaaS team I worked with integrated a third-party login. They tested with a wildcard redirect—anything ending in their domain. An attacker registered a lookalike domain and tricked users into authenticating. The attacker got tokens and accessed internal dashboards unnoticed for weeks.

[13:30]Vlad: That’s a scary one. How was it discovered?

[13:45]Priya Deshmukh: It was a lucky catch. An engineer noticed strange audit logs—logins from odd IPs at odd hours. They dug into the OAuth logs and found tokens issued to unknown redirect URIs.

[14:10]Vlad: What’s the lesson here for teams building with OAuth?

[14:30]Priya Deshmukh: Always whitelist exact redirect URIs. Never use wildcards. And monitor your OAuth logs for anomalies. Automation helps here—some providers let you restrict allowed URIs at the config level.

[15:00]Vlad: Let’s talk about credential stuffing. How do weak authentication flows open the door to these attacks?

[15:25]Priya Deshmukh: Credential stuffing is where attackers use leaked username/password pairs from other breaches to log in. If your app doesn’t have rate limiting, multi-factor authentication, or strong password policies, it’s an easy target—especially in the cloud, where public endpoints are exposed.

[16:00]Vlad: So even if the leak was elsewhere, your service can get hit?

[16:20]Priya Deshmukh: Exactly. Attackers are opportunistic. They’ll try huge lists of credentials on every login portal they can find. If you’re not watching for patterns—lots of failed logins from the same IP, for example—it’s easy to miss until accounts are compromised.

[17:00]Vlad: Let’s pivot to secrets management, since credentials aren’t just user passwords. What are the classic mistakes here?

[17:30]Priya Deshmukh: The big one: hardcoding secrets in source code. I see API keys, database passwords, and cloud provider tokens checked into repos all the time. Once they’re in git, they’re hard to fully remove, and if your repo is public or gets leaked, attackers have a field day.

[18:10]Vlad: Why does this still happen, even with all the warnings?

[18:30]Priya Deshmukh: Honestly, convenience. Developers want things to 'just work'—so they stick a key in code to test something and forget to take it out. Or a sample config file gets committed and copied everywhere. Sometimes it’s a lack of tooling or process.

[19:40]Vlad: What about secret sprawl? Can you explain what that means?

[20:00]Priya Deshmukh: Secret sprawl is when secrets end up scattered across too many places—code, environment variables, logs, container images. The more copies, the harder it is to rotate or revoke them, and the more places they can leak.

[20:40]Vlad: Let’s pause there. Logs and images—those feel like hidden risks. Can you give an example?

[21:00]Priya Deshmukh: Sure. I’ve seen logs output full request headers, including Authorization tokens. Or Docker images get built with .env files inside—so anyone who pulls the image has the database password. These are the kinds of things that slip through code review and only show up during a post-incident analysis.

[21:15]Vlad: And in CI/CD pipelines? That’s another area that seems risky.

[21:40]Priya Deshmukh: Big time. Pipelines often need secrets to deploy artifacts or run tests, but if you don’t protect those variables, anyone with access to the pipeline can see or exfiltrate them. Sometimes secrets get baked into build logs or output by accident.

[23:00]Vlad: Let’s get into a real incident. Can you walk us through a case where credentials were exposed through a build artifact?

[23:40]Priya Deshmukh: Absolutely. A fintech company I worked with was moving fast—they automated everything. But one day, an engineer found a credentials file inside a deployed container. It turned out the build script copied a secrets file into the image for testing and forgot to remove it before pushing to production. Attackers found the image in a public registry and used the keys to access internal APIs.

[24:30]Vlad: Ouch. What was the fallout, and how did they fix it?

[24:55]Priya Deshmukh: Fortunately, it was caught before major damage, but they had to rotate all affected secrets, audit every image, and add scanning tools to catch future leaks. Now, they use a secrets manager and strict build checks before anything goes out.

[25:00]Vlad: That brings us to a big debate: how do you balance developer velocity with good security hygiene? Sometimes it feels like security gets in the way.

[25:30]Priya Deshmukh: That’s the eternal tension! But I’d argue that security is part of velocity. Recovering from a breach is way slower than doing things safely up front. That said, tools and automation can make security less intrusive—like automated secret scanning or managed identity providers.

[26:00]Vlad: I see your point, but I’ve heard some devs say secret management tools are too complex or slow down onboarding. Thoughts?

[26:30]Priya Deshmukh: That’s fair. Some tools are clunky. But it’s worth investing in ones that fit your workflow. A little friction now is better than a huge incident later. Plus, there are new solutions that integrate seamlessly with CI/CD and cloud providers.

[27:00]Vlad: It sounds like it’s about finding the right balance and tooling. Before we move on, any last advice for teams struggling with secrets?

[27:20]Priya Deshmukh: Inventory your secrets. Know where they live and who has access. Use automation to scan for leaks, and rotate secrets regularly. And always assume something will leak—design your architecture so that a single secret compromise isn’t catastrophic.

[27:30]Vlad: That’s a great point to wrap this half. When we come back, we’ll dig into supply chain risks and why so many cloud breaches come down to unsafe defaults. Stay with us.

[27:30]Vlad: Alright, welcome back. We left off discussing some of the foundational issues with cloud authentication and how easily teams can trip up. I want to shift gears a bit and get into some real-world scenarios. Can you walk us through a case study where poor secret management led to significant trouble?

[27:52]Priya Deshmukh: Absolutely. One that comes to mind involved a SaaS platform where API keys were accidentally committed to a public repository. The team thought they were safe because the repo was only public for an hour, but within minutes, automated bots had harvested those keys. The attackers used them to spin up dozens of expensive compute instances, racking up thousands in costs before it was caught.

[28:17]Vlad: That's a nightmare scenario. What led to those keys being exposed in the first place?

[28:34]Priya Deshmukh: It was a classic case of local development convenience gone wrong. Developers were storing credentials in a .env file, but someone added that file to version control by accident, and the .gitignore was misconfigured. They only realized the mistake when billing alerts started firing.

[28:51]Vlad: Ouch. I hear about this more and more. What proactive steps could have prevented this?

[29:07]Priya Deshmukh: First, using a secrets management service—something like AWS Secrets Manager or HashiCorp Vault—rather than local files. Second, enforcing pre-commit hooks that scan for credentials. And finally, setting up alerting for unusual cloud spend, which in this case at least helped them catch it quickly.

[29:28]Vlad: Let's talk about the supply chain. It's become a huge concern, especially as cloud apps pull in so many dependencies. What do you see as the biggest supply chain risks?

[29:44]Priya Deshmukh: The biggest risks are dependency confusion and malicious packages. With so many third-party modules, it's easy for a compromised or typo-squatted package to slip in. And once it's in your build pipeline, it can access your environment, steal secrets, or inject backdoors.

[30:03]Vlad: Have you seen a real incident involving a supply chain attack?

[30:16]Priya Deshmukh: Yes, one client had an internal package with the same name as a public one. They forgot to scope it, so when a developer rebuilt their local environment, the package manager pulled in the public version—which was malicious. It exfiltrated environment variables as soon as it ran.

[30:35]Vlad: That’s subtle and scary. How can teams protect themselves from these kinds of mix-ups?

[30:48]Priya Deshmukh: A few things: always scope internal packages, use private repositories, and pin dependencies to specific versions. Also, use tools that scan for vulnerabilities or known-bad packages regularly.

[31:09]Vlad: You mentioned safe defaults earlier. What are some unsafe defaults you still see in cloud environments today?

[31:25]Priya Deshmukh: Open S3 buckets are the classic example—storage left public by default. Another is cloud functions or APIs without authentication, simply because the default configuration is 'open to the world.' And default admin passwords left unchanged on hosted services.

[31:45]Vlad: Let’s go deeper on APIs. Why are they such a common weak point?

[32:00]Priya Deshmukh: APIs are often spun up quickly, and developers might skip authentication for convenience. Or they might use weak API keys hardcoded in code. Since APIs are meant to be accessible, attackers know to scan for endpoints with no auth or weak controls.

[32:17]Vlad: If you had to prioritize—auth, secrets, supply chain, or defaults—which do you think is most often neglected in modern cloud teams?

[32:32]Priya Deshmukh: Honestly, it's probably safe defaults. Teams are moving so fast, and there’s this assumption that cloud providers handle security out of the box. But unless you explicitly lock things down, you’re probably exposed somewhere.

[32:50]Vlad: I’d love a quick story about a team who did things really well. Maybe a positive case study this time?

[33:08]Priya Deshmukh: Sure. There was a fintech startup that implemented a zero-trust model from day one. Every resource had least-privilege IAM policies, secrets were rotated automatically, and every code push triggered a dependency scan. They caught a vulnerable library before it ever hit production, and their audit logs helped them pass a compliance check with flying colors.

[33:28]Vlad: That’s impressive. It sounds like a lot of work, but it paid off. For teams who feel overwhelmed, where should they start if they want to raise the bar on cloud security?

[33:45]Priya Deshmukh: Start with inventory. Know what you have—what services, what APIs, what secrets. Then lock down access. Even simple steps like enabling MFA for all cloud accounts and rotating keys regularly make a huge difference.

[34:03]Vlad: Let’s do a rapid-fire round if you’re up for it. I’ll ask some quick questions; you give short, punchy answers. Ready?

[34:06]Priya Deshmukh: Let’s do it.

[34:09]Vlad: Most overlooked cloud security tool?

[34:11]Priya Deshmukh: IAM policy simulator.

[34:13]Vlad: One thing to never hardcode?

[34:15]Priya Deshmukh: Credentials. Ever.

[34:17]Vlad: Best way to detect leaked secrets?

[34:20]Priya Deshmukh: Automated scanning tools tied to your CI/CD pipeline.

[34:22]Vlad: First thing to check after a supply chain alert?

[34:24]Priya Deshmukh: Audit recent dependency changes.

[34:26]Vlad: How often should secrets be rotated?

[34:29]Priya Deshmukh: At least every quarter, or immediately after any incident.

[34:31]Vlad: Favorite cloud security best practice?

[34:33]Priya Deshmukh: Principle of least privilege. Always.

[34:35]Vlad: What’s the most dangerous cloud myth?

[34:37]Priya Deshmukh: That the provider secures everything for you.

[34:41]Vlad: Alright, that was great! Let’s slow down a bit and talk about mistakes. What are some subtle mistakes that are easy to overlook in cloud security?

[34:58]Priya Deshmukh: One is misconfigured RBAC—giving users or services more permissions than needed. Another is assuming private endpoints are actually private, when sometimes they're still accessible from the internet due to VPC misconfigurations.

[35:15]Vlad: Can you give an example where RBAC went wrong?

[35:31]Priya Deshmukh: Definitely. I worked with a retail company that allowed a service account intended for analytics to have full admin privileges. That account’s credentials were accidentally leaked, and an attacker deleted several production databases. The blast radius was way bigger than it needed to be.

[35:51]Vlad: That’s brutal. So, even minor oversights can have huge consequences. Let’s circle back to secrets for a second. Some teams use environment variables, some use secret managers—what’s your take on the trade-offs there?

[36:09]Priya Deshmukh: Environment variables are okay for ephemeral secrets if you’re careful, but they’re often exposed in logs or error dumps. Secret managers add complexity, but they give you audit trails, automated rotation, and tighter access controls. For anything sensitive, use a proper secret manager.

[36:27]Vlad: What about secret sprawl? With microservices, secrets multiply fast.

[36:40]Priya Deshmukh: Absolutely. The key is centralization and automation. Use a secrets manager with strong access controls, and automate secret injection so humans don't have to handle secrets directly.

[36:55]Vlad: Let’s touch on detection. How do you recommend teams monitor for suspicious activity in their cloud environments?

[37:10]Priya Deshmukh: Enable logging everywhere, especially for admin actions and API calls. Use anomaly detection to spot unusual behavior, like a sudden spike in resource creation, or logins from unexpected locations.

[37:23]Vlad: Is logging enough, though? What’s the next step after logging?

[37:38]Priya Deshmukh: Logging is just the start. You need alerting and regular review. Set up alerts for high-risk actions, and actually look at your logs—don’t just store them. Some teams automate log analysis with SIEM tools.

[37:52]Vlad: Let’s get into automation. Is there a risk that automation itself can create new vulnerabilities?

[38:09]Priya Deshmukh: Definitely. Automation scripts often run with high privileges, and if they’re not locked down, a compromised script or CI/CD pipeline can be a huge attack vector. Always use least privilege for automation, and rotate any credentials those scripts use.

[38:23]Vlad: We’ve hit on a lot of technical stuff. I want to ask about culture. How do you get teams to actually care about cloud security day-to-day?

[38:40]Priya Deshmukh: It starts with leadership setting the tone—making security a shared responsibility, not just the security team’s job. Regular training, blameless postmortems, and celebrating people who catch issues early all help build the right mindset.

[38:57]Vlad: That’s so important. Okay, let’s talk about build pipelines. Where do you see common gaps in CI/CD security for cloud apps?

[39:13]Priya Deshmukh: The biggest gaps are hardcoded credentials in pipeline configs, overly broad permissions for build agents, and lack of isolation between build stages. Also, not scanning artifacts for vulnerabilities before deploying.

[39:29]Vlad: What’s your take on open-source dependencies in cloud-native apps—are they a blessing or a curse?

[39:45]Priya Deshmukh: Both. They speed up development but introduce risk. The key is to monitor for vulnerabilities, keep dependencies updated, and only use well-maintained libraries. Don’t just pull in code blindly.

[40:00]Vlad: Let’s say a listener is running a cloud app and suddenly discovers an open S3 bucket. What’s the triage process?

[40:16]Priya Deshmukh: First, lock down the bucket—change permissions immediately. Next, check access logs to see if anyone accessed sensitive data. Rotate any exposed secrets, and notify stakeholders. Then do a root cause analysis to prevent recurrence.

[40:34]Vlad: How do you balance speed and security? Teams want to ship fast, but security can slow things down.

[40:50]Priya Deshmukh: It’s about automating as much as possible—security checks in CI/CD, automated dependency scanning, and templates for secure infrastructure. Make the secure way the easy way, so teams don’t have to choose between speed and safety.

[41:08]Vlad: We’re getting close to the end, so let’s get practical. Can you walk us through an implementation checklist—a step-by-step that teams can follow to avoid the pitfalls we’ve talked about?

[41:15]Priya Deshmukh: Absolutely. Here’s a checklist I recommend:

[41:20]Priya Deshmukh: First, inventory all cloud resources and APIs. You can’t secure what you don’t know about.

[41:25]Priya Deshmukh: Second, enable and enforce MFA on all cloud accounts.

[41:28]Priya Deshmukh: Third, use a secrets manager, and rotate secrets regularly.

[41:32]Priya Deshmukh: Fourth, lock down permissions—use least-privilege IAM roles and RBAC everywhere.

[41:36]Priya Deshmukh: Fifth, scan dependencies and containers for vulnerabilities before deploying.

[41:40]Priya Deshmukh: Sixth, set up logging and alerting for all admin actions and sensitive data access.

[41:45]Priya Deshmukh: Seventh, review cloud configuration for unsafe defaults—like public buckets or open endpoints.

[41:50]Priya Deshmukh: And finally, run regular tabletop exercises or incident response drills so your team knows what to do if something goes wrong.

[41:57]Vlad: That’s a fantastic checklist. We’ll be sure to include a written version in the show notes.

[42:05]Vlad: Before we wrap, I want to bring up one last quick mini case study. Have you seen an example where ignoring safe defaults led to a headline-worthy incident?

[42:22]Priya Deshmukh: Yes, there was a startup that deployed a new database cluster and left it with default networking settings. The database was exposed to the public internet with no password. It took just a few hours before someone discovered it and wiped the data. The fallout was massive—they lost customer trust, and it set them back months.

[42:40]Vlad: It’s amazing how something so simple can have such a huge impact. Any final advice for teams building in the cloud?

[42:53]Priya Deshmukh: Don’t assume defaults are safe. Take the time to review every service you spin up. And make security part of your regular workflow, not an afterthought.

[43:07]Vlad: Before we say goodbye, let’s hit on three takeaways for listeners today. Want to kick us off?

[43:13]Priya Deshmukh: Sure. First, always secure your secrets—never hardcode, and rotate often.

[43:19]Vlad: Second, treat your supply chain as a potential attack vector. Audit dependencies and use private registries.

[43:23]Priya Deshmukh: And third, never trust default settings. Review and lock down every new resource.

[43:29]Vlad: That’s a great summary. Let’s look ahead a bit. What trends should teams watch for in cloud security?

[43:43]Priya Deshmukh: I’d say watch for more automated attacks, increasing use of AI for both offense and defense, and a greater focus on securing the software supply chain end-to-end.

[43:51]Vlad: Any resources you recommend for teams who want to go deeper?

[44:02]Priya Deshmukh: Definitely check out the Cloud Security Alliance best practices, and consider running through some cloud provider security labs—they’re hands-on and really helpful.

[44:11]Vlad: Love it. We’re almost out of time, so I want to thank you for joining us and sharing so many practical insights.

[44:16]Priya Deshmukh: Thanks for having me. This was a great conversation.

[44:23]Vlad: To all our listeners—remember, security is a journey, not a checkbox. Review your cloud setups, keep learning, and don’t be afraid to ask for help.

[44:29]Priya Deshmukh: And keep your secrets secret!

[44:36]Vlad: We’ll leave it there. All the links and the checklist will be in the show notes. Until next time, stay secure out there.

[44:40]Priya Deshmukh: Take care, everyone.

[44:45]Vlad: This has been Softaims. Thanks for listening.

[44:55]Vlad: And for those who want to dig in, don’t forget to subscribe for more deep dives on cloud and security topics. Goodbye for now!

[45:00]Priya Deshmukh: Bye!

[45:05]Vlad: Alright, that’s a wrap. Our producer will cut it here.

[45:09]Priya Deshmukh: Great session. Looking forward to hearing it back.

[45:13]Vlad: Thanks again for your time and sharing so much actionable advice.

[45:17]Priya Deshmukh: Anytime. Let’s catch up again soon.

[55:00]Vlad: Alright, we’re officially signing off at the 55-minute mark. Thanks to everyone for joining us for this episode of Softaims. Keep building, keep securing, and we’ll see you next time.