---
title: "Liran Tal — Cloud native application security, what’s a developer to do?"
url: https://appsecpodcast.com/liran-tal-cloud-native-application-security-what-s-a-developer-to-do/
date: 2021-03-09
duration_seconds: 2527
guests: ["Liran Tal"]
topics: ["Software Supply Chain", "Cloud and Infrastructure", "API Security"]
audio: https://www.buzzsprout.com/1730684/episodes/8122575-liran-tal-cloud-native-application-security-what-s-a-developer-to-do.mp3
transcript: true
---

# Liran Tal — Cloud native application security, what’s a developer to do?

*March 9, 2021 · 42 min*

with [Liran Tal](https://appsecpodcast.com/guests/liran-tal/)

on [Software Supply Chain](https://appsecpodcast.com/topics/supply-chain/), [Cloud and Infrastructure](https://appsecpodcast.com/topics/cloud-and-infrastructure/), [API Security](https://appsecpodcast.com/topics/api-security/)

[Audio](https://www.buzzsprout.com/1730684/episodes/8122575-liran-tal-cloud-native-application-security-what-s-a-developer-to-do.mp3)

## Show notes

Cloud-native development gives engineers control over more of the stack, but it also gives them more security decisions to get wrong. Liran Tal, an open-source contributor and developer advocate, joins Chris and Robert to explore that expanding responsibility. They define cloud-native applications, examine containers and infrastructure as code, and discuss how security ownership changes when developers choose runtimes, dependencies, and deployment configurations. Liran explains why vulnerability severity alone is a poor guide to remediation and why usable feedback matters more than another long list of findings. The conversation also covers practical container-building mistakes, production behavior, and the value of asking what could go wrong while writing code. His advice centers on awareness, helpful defaults, and tools that support developers.

The Application Security Podcast is brought to you by [Security Journey](https://www.securityjourney.com/).

About Security Journey  
Security Journey provides application security education for developers and everyone in the software development lifecycle.  
→ [Learn more about Security Journey](https://www.securityjourney.com/)

Connect with Liran Tal:  
→ [Liran Tal’s website](https://lirantal.com/)

Mentioned in this episode:  
→ [Node.js](https://nodejs.org/)  
→ [Docker](https://www.docker.com/)  
→ [Kubernetes](https://kubernetes.io/)  
→ [Snyk](https://snyk.io/)

Chapters:  
00:00 Cloud-native application security with Liran Tal  
05:25 Defining cloud-native development  
07:26 What is changing in the cloud-native stack  
09:36 Who owns application and infrastructure security  
13:32 Security in the local developer workflow  
15:15 Threats in cloud-native applications  
16:46 Infrastructure as code and security visibility  
22:08 Least privilege and cloud configuration  
24:12 Helping developers take on new responsibilities  
27:27 AppSec practices in a cloud-native world  
29:31 Prioritizing vulnerabilities beyond severity  
31:49 Giving developers the tools to help themselves  
33:08 Building safer Node.js container images  
37:10 Differences between development and production  
38:40 Practical takeaways and a threat modeling mindset

## Transcript

*7,384 words · assemblyai*

**0:00 Chris Romeo:** Laurent Hall is an application security activist and longtime proponent of open-source software. He's a member of the Node.js Security Working Group, an OWASP project lead, author of Essential Node.js Security and O'Reilly's Serverless Security. He's leading the developer advocacy team at Snyk in a mission to empower developers with better dev-first security. Laurent joins us to talk about cloud-native and AppSec. We begin by defining cloud-native and the changes it's causing. We then get into the threats in a cloud-native world and the role of developers and AppSec with cloud-native. We hope you enjoy this conversation with Laurental. At Security Journey, we believe security is every developer's job. We work with our customers to help them build long-term sustainable security culture amongst all their developers. Our approach is to provide security education that's conversational, quick, hands-on, and fun. We don't do lectures. Instead, we let the experts talk about what's important. Modules are quick, 10 to 20 minutes in length. We believe in hands-on experiments, builder and breaker style, that allow your developers to put what they learned into action. And lastly, fun. Training doesn't have to be boring. We make it engaging and fun for the developers. Visit www.securityjourney.com to sign up for a free trial of the Security Dojo. Hey folks, welcome to this episode of the Application Security Podcast. This is Chris Romeo, CEO of Security Journey and co-host of said podcast. I'm also joined today by Robert Hurlbut. Hey, Robert.

**1:49 Robert Hurlbut:** Hey, Chris. Yeah, Robert Hurlbut, Threat Modeling Architect. Good to be here.

**1:53 Chris Romeo:** Awesome, awesome. And we're, we're going to learn something new today. which for me is something I try to do every day. It seems like I do learn something new every day.

**2:02 Robert Hurlbut:** Same here.

**2:02 Chris Romeo:** Sometimes I want the lessons, other times I don't, but that's the joy of the startup space, right? It's like sometimes you get taught something, but we're gonna talk about cloud native. And so we're joined by Laurental, who's been with us before. He is at Snyk. You're gonna have to remind us, Laurent, what your actual title is. I know it's something really cool, but if you could just catch us up on what you've been up to for the last couple of years since the last time we chatted.

**2:25 Liran Tal:** Cool.

**2:26 Robert Hurlbut:** Cool.

**2:26 Liran Tal:** Thanks, you guys, for having me today. Glad to be back on this. So yeah, I'm a developer advocate at Snyk. Snyk does a whole range of tooling. It's a security platform basically for cloud-native applications, which we'll dive into more. But my role specifically is all about discussing with developers, talking about all maybe their frustrations and how we can help, what is going on, researching a lot of open-source supply chain security issues. writing about this, what are these best practices that we're trying to create and curate to report and things like that. So I mean, this is me at Snick, but have been up to a lot of things since we last talked. I mean, it's like you just said, right? We're always trying to learn new things. So I've been diving a lot deeper into this, the cloud native space, but kind of like the ops part of it. So things that used to be very reserved for like sysadmins and ops before, things like the orchestration engine and deployment and all of those things. But now they're really at the hands of developers. So doing a lot of work there. So we'll dive into it more, but other things that have been happening recently have been around. So we launched this Snyk Advisor thing. This is like 6 months back, but it's such a cool project that I'm so excited about because this is, you could go to just, you Google the Snyk Advisor. If you go there, basically, Yeah. It's kind of like this experience for booking.com, but for open source, right? Because if you're a developer and you want to use an open source package, you're like, well, maybe it's maintained or not. Is it vulnerable? What's the community like around it? So this is exactly what the Advisor is. You just throw in or search for a specific package for you. And at that point, we give you all of those metrics based on that open source package, like how it's been like. And you have this. 360 view around the security, the popularity, the maintenance, everything around it to get you to do this thoughtful consideration and decision of whether you want to use that package or something else. So, I mean, that has been very exciting. So all of those things kind of like really happening recently over here. But how has it been about yourself? How's it going?

**4:40 Chris Romeo:** Oh, I think both Robert and I can say we are gainfully and happily employed because we know that the world of application security just keeps needing everything that we can offer.

**4:52 Robert Hurlbut:** Sure.

**4:52 Chris Romeo:** And that goes for every— all of us as an industry as well. But I know we want to talk about cloud native today and how cloud native intersects with application security and a lot of that really interesting details. But I think we got to start by just, Laurent, having you give us your perspective on what is cloud native, because I feel like it's one of those things that could mean different things to different people. It's like when I go visit a company and they're like, we do agile, and I'm like, oh, that's awesome.

**5:24 Liran Tal:** What does that mean?

**5:25 Chris Romeo:** Can you explain that to me? Because there's not one agile, there is a view of agile. I don't know if cloud native is like that, but enlighten us a bit about what is cloud native.

**5:35 Liran Tal:** It's a good start. So, to me, I think cloud native is basically where applications have been built in a way that they could benefit and function in the world of cloud, which when you say cloud, that usually translates to you don't operate the infrastructure. You get something as a service and you operate— think about it in terms of you declare what you want in a declarative way, not in an imperative. So you say, I want 3 replicas of this function or this microservice. And you don't care what's going on behind the scenes. This is someone else's basically job and responsibility to figure this out. So when you build cloud-native applications, it means you need to think of those things. You need to think of scale, of how do you adapt to those areas? So if it's a function that you write, you think about it in terms of something very small, something very purposeful that you write, and you do not care if this gets triggered with a scale of 100 hits a minute or 1,000, because that is someone else's responsibility to care for you and elastically basically scale that up and down as needed. So I think as a developer, it has different meanings. For example, I think developers will think about cloud native in terms of, well, if we need to do event-based systems, so they think in terms of instead of synchronous operations, they think asynchronous. So they think message queues and all the Kafkas and And so on. And they think of streams and things like that. So it is a concept change, I think, for developers, but also the security applies to it. Because that's, I think, what is fascinating is what is security in a cloud-native world, which is kind of like where I think we'll want to dive into.

**7:26 Robert Hurlbut:** So what's changing in cloud-native space? I know it's been around for a while, but is there anything new? I mean, just in the latest updates and so forth that are out there?

**7:38 Liran Tal:** Yep. So I think maybe, I mean, the adoption is going to grow and grow. We're seeing that all around, more people are using, well, those cloud-native related artifacts. And I can give, I mean, there's so many examples. If I go and give, for me, an extreme situation, frontend developers, think about frontend developers in terms of cloud native. That is also like, what is even the connection, the relation that's like, it's cloud and frontend developers don't do those things that you talk about in terms of the bread and butter of cloud, which is much a little bit more ops, more containers. But there's a lot there for frontend developers. For example, they— and I think a lot of developers don't really understand that they are cloud native developers at this point because What I've seen, I have friends who are doing cloud development on Firebase. So they're using Firebase and they're writing their frontends and they're pushing some code, which is a backend, but they don't think about it in terms of a backend, but it's a function that they have there, a myriad of functions. And they don't think about it too much. And it's just there that someone is responsible, that whole stack to do this. Or think about someone, a frontend developer, again, maybe deploying a website. They do not need to— if they do it with Netlify or Vercel, they don't need to care about the SSL part, the edge, how do you optimize. All of those things have gone beyond what we have done before as frontend developers 15, 20 years back. This has gone completely outside of our control or at least our responsibility into someone else to optimize that for us. And we need to understand how that works. That's the cloud native part. the cross-origin headers, the API gateways, all of those things that relate to it. But beyond that, we do not care how that scales. We do not care how that— I mean, we care about how it scales, how it performs, but it's not our responsibility to operate it. This is someone else operating it for us.

**9:36 Chris Romeo:** In the model that you're thinking through here in a cloud-native world, very clearly you've said, hey, the developers are They don't have to worry about the infrastructure components then. If that's the case, who owns that in the average company? Is it the site reliability engineers? Is it somebody else I'm just not aware of? Where does that function happen?

**9:56 Liran Tal:** Yeah. So I'm definitely trying to put the extreme part. I don't think that developers don't care or it's not their responsibility, but more like it's not the knobs that we have used to tune when we deployed something. Now there is something that we declare what we want and it just gets there. there's an entire infrastructure that gets it there. And this is, I think, where security ties into it as well. So if I take, for example, let's go back more natively backend security-related examples. And that would be if I deployed a microservice in Node recently, then I don't worry too much about how that gets orchestrated in the cloud. I know that I just put maybe If I wrap that in a function or if I wrap that in a container, I just do it. I have my Dockerfile and something gets it to deploy or whatever. But I think this is where security extends beyond what you have used to think about until today to now more of it. So if I'm a developer and now you're talking to me about security, the first things that I think comes to my mind are, well, there's my app security. So my code, my first-party code, what I actually write. And if I'm thinking a little bit more deeper, I'll think about my dependencies. So the dependencies inside my codebase, right? Whatever I bring in. And this ties into this software composition analysis, this whole world of open source supply chain and so on. Usually at that point, I think most people kind of stop thinking of how security trickles down to their app at that point. And my cloud native vision to what security is for those developers, and this is, I think, what is changing, is it's now more than this. It now extends because it's now their container image. And when you talk about the container image, even then at that point, people will say, yeah, of course, it's the dependencies in the container. So maybe I shouldn't bring in a very vulnerable base image, or maybe I shouldn't bring in apt-get install imagemagic because that might install a lot of vulnerabilities because imagemagic is very prone to those. But again, it's not just that. It's kind of like the container is also running and it's using a runtime. So the vulnerabilities are also in the runtime itself. So Node can be vulnerable, maybe running an old version of Node that has vulnerabilities. It's not out of support. It's just an older one. And Node releases every quarter or so security updates. So who knows? If you're not on top of it, it's not just the dependencies, it's the Node runtime itself.

**12:33 Chris Romeo:** Yeah.

**12:34 Liran Tal:** And then it kind of extends more, right? Because you're not operating a Kubernetes maybe cluster, but as a developer, just like you have maybe until today wrote your Dockerfile, now you're writing this Kubernetes YAML file. So this whole infrastructure as code now definitely relates to you. You as a developer definitely do this. You decide what is the replica set because you probably know what are your kind of functional or performance-related requirements from the application. And this is a place where you can make a lot of mistakes, right? This is misconfiguration issues that we're seeing, untrusted, unsecured S3 buckets or whatever. So this is, I think the change is not, I'm not saying the change is amazing in terms of we're now understanding Kubernetes YAML and all of this. This has been there, right? The adoption is going to grow more, but I think we're now looking at developers owning more of that. And kind of like relating more of that to their day-to-day job. That is what I think we're seeing more and more of.

**13:32 Chris Romeo:** Yeah. So, kind of a developer-first approach for everything, right? Because even in a cloud-native world, we don't want to be so siloed where it's like, oh, well, these folks over here, they just write code. They don't know anything about the infrastructure. You still have to know something about where the end product is going. I mean, you got to test it locally on your own machine, right? Like, you have to replicate what's going to happen in production through your own Yep. So, I'm curious if you have seen or if you have thoughts on, when I think about this whole idea of cloud-native, and I promise we're going to focus deeply on security in just a second, but I've got this idea I want to kind of bounce off you as someone who's thought about this in more depth. Are large enterprises going to struggle with this of saying, like, can a large enterprise right now go, We have decided we are going cloud-native. It's like we're carbon-neutral by 2025, and we're cloud-native by 2026. Is that something that's even possible, or is that something that's going to take a decade or more for that to occur?

**14:38 Liran Tal:** I think it's happening, and it will probably happen whether we want to or not. There are obviously those, I don't want to say organizations or enterprises, but definitely those entities which will need a hybrid model and offline kind of things. We can think about governments and banking and so on. But there's simply a lot that we're gaining from putting things on the cloud that I don't think anyone is betting against that and thinking, oh no, we're going to go back and manage our own data center. That's not a thing anymore.

**15:13 Robert Hurlbut:** Yeah.

**15:15 Chris Romeo:** Yeah. So what about the threats? So as I promised our audience, we're going to quickly make a turn back to application security. So what are the different threats then as we prepare for a cloud-native world? And are they different threats than what we've been thinking about for the last 10 years?

**15:31 Liran Tal:** Yeah. So I think they are different, probably. If you've been a pioneer of cloud-native kind of things 10 years ago, you've been a pioneer of that, and that's kind of what we did before. But as more people kind of push into it. Yes, the threats are all around, I think, beyond what you're managing from the lens of a developer. It's just more beyond your own code and your app stack. Just my think of it is kind of like your Node.js app attack surface really just got bigger at this point. The moment you deployed something to the cloud, it's just bigger. Realistically saying it, it was probably bigger before, right? But the moment that you have done that and kind of like you as a developer kind of like, you You're like, you know, the whole movement of DevOps and devs kind of like full stacking, owning their Dockerfiles or Kubernetes and so on. You are now effectively, you know, have increased the attack surface just because, you know, there is more there. And it's anything from misconfigurations to just the fact that, you know, there could be a vulnerable runtime, which maybe in the past, you know, who cares about, you know, who manages the runtime? That's, I don't know, the sysadmin, the DevOps person, whatever the SRE is. But now it's you, right? You write the Dockerfile as a developer.

**16:45 Chris Romeo:** Yeah.

**16:46 Liran Tal:** And I think that is the context change that have been added. I have a really cool example from a friend about Firebase. That's why I used that example before as well. So they ended up figuring out a bit late into time with an app they developed is that basically anyone could have signed up to the app, just like register and get any information about everyone else in that app. So think about like a database, like a phone book, but then everyone can see everything else. And so there were 2 layers of mistakes or misconfigurations that were done. So the first of all was the fact that they didn't gate any, they didn't provide anyone the ability to register. It was a closed system. But the fact that they didn't expose it didn't mean that the functionality existed on the bare bones of what the authentication stack that Firebase provided. So anyone could actually register even though they didn't expose it in any possible way. And then that classic misconfiguration where they didn't really do authorization. So once you authenticated, at that point, if you wanted, you could pull in information of someone else. Now, they haven't figured out the problem to begin with was because— so this is all managed in this Firebase functions.yaml file, right? Yeah. Push it out. And it was just basically going through probably a tutorial or whatever. And all of them basically has these rules of match document asterisk asterisk, basically everything, then allow read, comma, write only to people who are not— to anyone who can actually— who's logged in. But if anyone can register, at that point it's done. And this misconfiguration is I think what we need to help developers with, finding those those things for them because yeah, this is now becoming this kind of like, they didn't need to implement the authorization system. This is all based on Firebase SMS login and all of those things. So this is amazing, right? This is the serverless, the cloud-native world that they're benefiting from. But they still have to configure these. By the way, it's like 4 lines of declaration of what they need to access that function. And they've got it wrong. And they've realized this. few months over. And this was probably a few hundreds of thousands of records there and so on. This is a real-life production app, and this is what happened. So I think this is where we need to concentrate the effort with explaining to developers where things could go wrong. And this developer-first approach of telling them where exactly we find the things. So the fact that IaC is now very, I think, ubiquitous, right? It's everywhere, infrastructure as code. We can also refer to it. And it's very now easy, I think, to also relate to developers because we can pinpoint line numbers just like you would do in an IDE, a debugger or something, and tell them, this line is incorrectly exposing authentication to— sorry, registration for everyone. Or you could say the same way, if you're highlighting a Kubernetes YAML file, you could say that that YAML declaration for this pod is actually showing that there's no— like you're missing out restricting the user to be non-root or things like that. So all of those things that we can just, you know, it's really easy to like relate that to developers. That's where I think this is going.

**20:24 Chris Romeo:** Yeah, it sounds like you're going to have more— it's going to be in a cloud-native world easier to take security controls and apply them in a standard way across things like, as you're describing these security misconfiguration issues, And I could see how you'd be able to write tools and things that would detect that. And even in your build pipeline, you're checking those configuration files, you're throwing an error saying, hey, there's something wrong here. And so, as I'm hearing you talk about cloud native, I'm coming to this realization that really the threats aren't going to be that different than what we've dealt with in the past. There's not like new categories of problems. You still got all of the same things that we had to consider when we started going to the cloud 20 years ago or whatever. The same challenges are there. I think in the early days of cloud, we had this idea that there's a lot of threats that are going to come from the infrastructure provider. And I think history has shown us that that was a threat that we were worried about that didn't really ever come to fruition. I'm searching my own memory banks here thinking, can I think of a time where a cloud provider, where there was a giant incident and it was a result of the cloud providers backdooring somebody's running systems?

**21:38 Robert Hurlbut:** Yeah.

**21:38 Chris Romeo:** I mean, there certainly have been Offline, you know, when the East Coast goes offline from a certain cloud provider, like that's a big issue, but that's a reliability, that's not a security thing. And so that's where I'm kind of landing when I think about the threat landscape. Like it's probably not that different. Cloud native is not changing things that much from a threat perspective. It's more changing, making us— it's optimizing how we're going to be able as developers to push out new products and things because there's more of a standardized approach to everything that we're doing.

**22:08 Liran Tal:** Yeah, I agree. I think it's totally right. Like, it's not, I think, dramatically changing. It's not dramatically changing the threats themselves. But rather, I think what is happening is some threats simply become like more obvious, more like they need to be more highlighted than before. So, you know, misconfiguration, it's probably going to be a stop 10 for like, you know, the next edition or whatever. And it's going to be, you know, I think, you know, highlighted more. And it's Well, how do you do least privilege? How do you do that? Because I've done some cloud before in AWS, and it's— I don't want to say it's scary, right? But there's just a lot of Lego pieces that you need to tie in together. So developers and engineers making mistakes, it's not that uncommon. It's not that surprising. It's like so many things to pull in together. So it is obvious at some point you're going to do some mistake. You're going to accidentally expose a IAM role or an overprivileged function, which shouldn't be. It's going to happen.

**23:04 Robert Hurlbut:** Yeah.

**23:04 Liran Tal:** it's going to be even harder because especially because cloud native is also, by the way, it's very cheap. If you need another environment, just fire it up. Someone is paying for it, but that's it. It's easily scalable. So what happens if you have a production environment and a staging environment and some data leak between them, or you put some test function in the cloud, but you forget to to block access to it. No one then— how many people, developers, have you seen that go after they finish something and say, well, let's clean up that environment. I don't need that test function anymore. People forget about those functions. They end up being overprivileged because they just tested something and it just exists. That's how you get all of those data leaks and incidents. So I think what happens is just like as you have this OWASP Top 10 for serverless, It's just highlighting specific threats that are more, you know, you are— it's like web risk that you will be more prone to make those mistakes. And that's what we want to, like, help you kind of, like, remediate first, right? This is the whole story.

**24:12 Robert Hurlbut:** How would developers— because it does sound like even though there's a lot of things that are the same or very similar, how would a developer realize, for example, that, They need to think more about configuration. They need to think about, obviously, authentication, authorization, other things that they know about, but in a slightly different environment. I mean, how would they, you know, that role change in some ways, but still the same, you know? So, are there some good recommendations or thoughts on helping a developer make some switches there to, if they're now going to focus on cloud-native apps?

**24:51 Liran Tal:** Yeah, it's a great question. I think I definitely don't have the silver lining answer for that one or the silver bullet for that, if so to say. It's a change that I think what I'm trying to do as well as being an advocate for security is making that shift change because once you're aware of the problem, that's like 50% of the solution, right? So that is definitely there. I think the more that we'll maybe create, I don't know, maybe like tooling, maybe like an IDE tool, an extension, just like developers add extensions to color their brackets ending and closing or whatever. We could give them tools. So as they write, if they wrote something, a Dockerfile that does from node:latest, at that point we'll tell them, no, no, no, no, no, wait, don't do it. Maybe getting the latest Node image is not the best thing you could do. There are different alternatives that you could take. This one, because it has these vulnerabilities, or maybe use a digest because you don't want to always pull latest versions of packages.

**25:51 Chris Romeo:** Yeah.

**25:52 Liran Tal:** images, because that's not an atomic operation. So you want to get always the same reproducible builds. So I think maybe if we take those tools and put them on a little bit shift left on the developers' IDEs, that could be one way to increase awareness and engagement, get their heads around this. But ultimately, I think some of the answer exists in the question that you asked. And that is, You gave the examples of how do we get developers to think about authorization in different ways. And I think I'm seeing more developers today, definitely by far, not trying to roll their own authentication. So I'm not seeing people asking me, well, how do I store passwords? And that has been a thing. If you remember the net 10, 15 years ago, that has been— Stack Overflow of 2004, that has been the question, right? How do you manage passwords? How do you do password reset? I don't know. How do you do password, whatever, forgot password? You do not ask those questions today as a developer because you're using these serverless, cloud-native kind of constructs that help you build authentication, authorization. You offload it to Okta, Auth0, whatever, all of those things that help you do it because you understand they have solved the problem and you need to get your app working in that function. But that's what I'm saying, right? That mindset kind of exists, We just need to highlight more of the issues that you might be making and telling you, just be careful in these areas.

**27:22 Robert Hurlbut:** Yeah.

**27:27 Chris Romeo:** You talked about IDE plugins. You talked about potentially some other tools and things. But when you think about how we do AppSec in a cloud-native world, what are other things that we should be thinking about? Are we applying the same traditional things that we think of? Like, when I think AppSec, I go right back to the secure development lifecycle, and I think, you know, from requirements to threat modeling all the way to incident response at the end of the day, are these pieces just the same, or are there other things that are unique in a cloud-native environment?

**28:04 Liran Tal:** I think the activities remain. What I think we could be doing better, and I think that could be more of a stance that we could build better activities upon, is probably the prioritization. Because I mean, I'm hearing this a lot, right? When you do an npm install and you're getting 50 vulnerabilities at that point, there's vulnerability fatigue, right? Because at that point, what exactly should I do with this? Yeah. And that's where I'm thinking we need to, first of all, provide real valuable data on what you're seeing with least false positives and things like that, but also prioritizing it. So an idea for how you would prioritize it is that old model of CVSS scoring, telling you if a CVSS score vulnerability has a score of 10, and then you say, well, stop everything, let's go fix it. That may be not working anymore, right? Because there's maybe 100 vulnerabilities. So what do you do at that point? You need to start somewhere. And I think that that model of the CVSS is a bit of an old model because it's been with us for a while. But I don't think people have utilized it to what it actually needs to help them with. That is prioritizing. Because there are so many metrics or indicators that you need to build into a vulnerability once you get it.

**29:30 Chris Romeo:** Yeah.

**29:31 Liran Tal:** once you're exposed to it. And that would be, for example, well, maybe there's a high vulnerability, right? It's high. It's getting like 9 or whatever. And then there's a medium vulnerability, a CVSS score of 6 or something. Which one would you do first, right? It's usually the 10, right? You say, let's move all the high vulnerabilities. But what if the indicators behind those vulnerabilities were actually this? The high vulnerability is maybe for a dev dependency, immediately unrelated, you dismiss it at that point. What if it doesn't have a fix? What would you do with it? You need to now explore if it's for SCA, for libraries you need to explore. Maybe there's an alternative package you could switch to or whatever, like rollback, start doing this. What if it doesn't have any POC exploit for it? So all of those things. that say that this is a high vulnerability, but it's not that really, I'll say, urgent to fix. Whereas that medium vulnerability is for a production dependency. And it has, hey, there's like a— it's like an XSS through somewhere, but there's an exploit for this in the wild. There's a PoC somewhere in Metasploit that someone could weaponize against you. And wait, there's also an upgrade for that specific version that is vulnerable. So So basically remediating that vulnerability is both more urgent and more easier, and like easier, right? So that's why like CVSS doesn't scale and prioritizing vulnerabilities in a different way like that scales more. And this is like an example from SCA, from just working with composition analysis, like open source packages and so, but it applies to the cloud native world the same way. If you have a Kubernetes cluster that you're running with some pods, maybe there's like a misconfigured Kubernetes. That has containers with vulnerabilities. You probably want to remediate that faster than some Kubernetes node, worker node that has maybe a lot of vulnerabilities, but nothing is misconfigured. It still lists privilege. It's not using the root user and so on. So it's vulnerable, but there's more chances if someone weaponizes that other misconfigured container or pod, they will be able to attack you a bit deeper and so on. I think that's kind of where it's going to go.

**31:49 Chris Romeo:** So it's a change in priority then, based on what you're saying. And I got to say, I love your perspective on this from— I can just hear the developer-first security kind of thought process that you're sharing with us here. And I think it's a mindset change for a lot of people, and security culture is something that I'm very passionate about as well. Like, how do we change— how do we help developers to have all the things that you're talking about? so that they don't need us, right? Like, we can be coaches and advisors, but it's not like we're the people that, oh, well, that has to come through us. Like, in the world you're describing, that's no longer even an option in this world. And so, I think that's a really neat way that you're approaching this. I know Snyk's approaching that from that same perspective as well. And so, I really appreciate that. I did want to touch on something that I have taken a look at. That was your best practice guide for building Node.js apps with Docker. I just wanted to give you a chance to kind of give us a little bit of a background and perspective on that. I know you do a lot of writing and things like that, and I'm a big fan. I read all that stuff that comes out from you.

**32:54 Liran Tal:** Thank you.

**32:54 Chris Romeo:** And a lot of it goes into the newsletter, our High Five newsletter that we send out once a week. Like, I'm like, if I see something from Laurent, it's like, oh yeah, that's going on my list. But tell us a little bit about that project and what we as developers can get out of that.

**33:08 Liran Tal:** Yep. So it's an interesting one because it started with basically thinking about maybe I should write something about how do we build containers in a safe way? Just build a container image for Node applications because that's where I'm from, but do it in a sane way. Now, the thing is, I know, I've Googled some of these myself to see what others are focusing on. And there's so many examples of wrong, people are missing in their tutorials a lot of wrong practices. So they will tell you, use from node latest or something. None will say, change to a user with least privilege. Or maybe they will say, if you need to put a secret in the container image, that's just like an argument that you pass in. Or God forbid, put it in the Dockerfile or whatever, something worse. So I've just seen so many examples of this. And this whole idea started with, I was tweeting out and I was saying, I've seen a lot of these issues in tutorials and how we educate the community around it. And would anyone be interested in learning how you do this, a very comprehensive guide on building container images? And I think the reaction to that has been amazing. I have hundreds of likes and people chiming in saying, yeah, do it, write it. I'm interested and so on. And that's what kind of motivated me to do this. And actually, I did this one a bit different. So this kind of cheat sheet on how do you containerize Node applications with Docker has been a bit different from the usual way that I curate content. And that has been, I'm actually— you were starting off with this base, I think 4 or 5 lines of code of a Dockerfile. Super simple, right? From Node, copy whatever you need, npm install.

**34:51 Robert Hurlbut:** Yeah.

**34:52 Liran Tal:** Command npm start. That's it. The super simple example, which by the way, some tutorials also stop there. They introduce you to Docker and then just leave you with that one to go off with. And then I go on one by one, why is that FROM an issue? What can go wrong with the COPY? Why you need multistage builds? How you do secrets properly? Why even— what has been going there for— we're talking about cloud native, right?

**35:18 Chris Romeo:** Yeah.

**35:20 Liran Tal:** The one thing that I haven't seen in any tutorial that I've read was that people start those Node containers just saying CMD, right? The command node start or npm start. And they're both wrong because if you're running this container in your development environment on Docker, that's fine. That will work. But in a cloud-native world, again, swarms and all of those things, orchestrations, the orchestrator needs to tell the Node app to die. The process needs to get killed because of some reason. I know it scales down or whatever. If you use any of those variations, none of them will cleanly kill the process. And that's why you actually need to work with exposed kind of like an init system inside a container that works with it, because the containers do not usually— the healthy thing is not to actually let them be process ID 1, because the kernel itself treats them differently. So even that one little piece of information could make miracles to your production environment, just because it could have a healthier ecosystem in your cluster rather than zombie processes running and lying around. So I love this work on the Docker containers, because it just showed me how how much we can educate the audience, everyone else better on this. I've definitely enjoyed interacting with developers about everything that they've learned around this. Probably we'll do more around this topic. So this has been a fun one for me.

**36:53 Robert Hurlbut:** So it really sounds like, and I was thinking this as we were talking earlier, that in terms of that shift for developers is, oh, well, I build everything locally. I know how it works locally. I just push it to the to the cloud and there I don't have to do anything, it just works.

**37:09 Liran Tal:** True.

**37:10 Robert Hurlbut:** And that's not the case. There are going to be differences and they need to be aware. Developers need to be aware of those differences as they're building. Just like before, whenever we build a dev, send it to staging, send it to production, there are going to be some differences and you have to be aware of those. Similar here. I mean, you try to do as much as you can to make them similar so that you're not getting into yourself into trouble. But it does sound like it's another world in some ways that you need to think about.

**37:41 Liran Tal:** It is, it is. You're kind of opening that door for me for my other passion, which is around software testing. And I have Yoni Goldberg, who is a curator around the biggest Node best practices on GitHub and so on. He's also worked with me on this one with the Node practices. But yeah, we always kind of tease each other because between doing unit tests and doing end-to-end tests, what's more important? What should you do more of? And you're just banging on that door of like, maybe I should not even have a staging environment, right? Maybe you have production, test everything in production, that's it. I don't know, maybe that's the way to do it. So there's just so much thought process that you need to pull into software to build it right. When you do it, you know, lately, it's costly, right? You end up doing rewrites or whatever. When you have security issues, it's also costly because it's incidents and whatnot. But yeah, it's, you know, testing all of these things is like, you know, everything just connects together.

**38:40 Chris Romeo:** So what, Laurent, would you say is your key takeaway or your call to action here? We'd like to leave our audience with some guidance from you about what do you want them to do as a result of our conversation about cloud native and how AppSec fits into it? Give them some homework.

**38:56 Liran Tal:** Cool. Cool. homework like that. Well, I mean, that reference to the 10 maybe best practices or something like that about containerizing the Node apps with Docker is, I think, a great start. If anyone needs to do it, that's already a great guide. But I think the thought process around what could go wrong at each stage is super important because it highlights so many things, so many concerns that you may have not thought about. So that's all. Shout out to everyone if anyone wants to read that one. The other thing I think is having that mindset to always ask yourself when you are building something is kind of like threat modeling with yourself, right? Like, what could go wrong? Like, if you're— that example I gave from a colleague or friend I have about that Firebase, that's a real-world example of that being basically exposed outside as an incident, a security incident. That again, that was like 4 or 5 lines of configuration of a file, but a mistake there would've been disastrous. So asking yourself, I'm doing something, but what is the meaning of putting asterisk asterisk something? Or what is the cloud doing with that data behind the scene in terms of how does it operate? That is super important because you know what you're configuring, at least you think you know, But maybe if you look from above, there's something that happens there that reads this and makes different decisions and comes to different conclusions based on what you provided. So your input is not very comprehensive. It's the same story all the time. You miss out on some Dockerfile directives, then you miss out on security. You miss out on Kubernetes security capabilities or whatever, then you're missing out on security. I would say, you know, have that mindset to think, you know, what am I probably doing wrong? The moment you'll ask it, you'll probably like start, you know, asking the relevant people or Google or whatever, and you'll figure out what you need to fix it. So just having that mindset.

**40:54 Chris Romeo:** Yeah, that's very helpful. Cloud native and security, what could go wrong? Laurent, thanks for spending time with us today and taking us down this path to understand cloud native and the intersection with security. and also with the best practices for Node and Docker. And thanks for helping to give that back to the industry so that people can create better containers. You know, it's good for all of us when the applications that are running out there are more secure. So thanks for taking the time today. We look forward to another conversation with you in the future. Who knows what it'll be about, but it'll be awesome. So thank you very much.

**41:30 Liran Tal:** Thank you, Chris and Robert. Thank you for having me.

**41:34 Chris Romeo:** Thanks for listening to the Application Security Podcast. You'll find the show on Twitter @AppSecPodcast or on the web at www.securityjourney.com/application-security-podcast. You can also find Chris on Twitter @edgeroute and Robert @RobertHurlbut. Remember, security is a journey, not a destination.

---

Source: https://appsecpodcast.com/liran-tal-cloud-native-application-security-what-s-a-developer-to-do/