cloud native, developers, security, vulnerabilities, cloud, node, container, firebase, threats, build, docker file, function, serverless, thinking, people, world, application, scale, kubernetes, expose
Chris Romeo, Robert Hurlbut, Liran Tal
Chris Romeo 00:00
Liran Tal is an application security activist and longtime proponent of open-source software. He's a member of the Node.js security working group, and OWASP Project Lead, author of essential Node.js security and O'Reilly serverless security. He's leading the developer advocacy team at Snyk in a mission to empower developers with better Dev verse security. Liran 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 Liran Tal. At Security Journey, we believe security is every developers' 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 Hurlburt. Hey, Robert.
Robert Hurlbut 01:50
Hey, Chris. Robert Hurlbut, Threat Modeling architect. Good to be here.
Chris Romeo 01:54
Awesome. We're going to learn something new today, which, for me, is something I try to do every day, seems like I do learn something new every day. Sometimes I want the lessons, other times I don't. But that's the joy of the startup space. It's like, sometimes you get taught something. But we're gonna talk about Cloud Native. We're joined by Liran Tal, who's been with us before, he is at Snyk, you're gonna have to remind us, Liran, what your actual title is. I know, it's something really cool. 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.
Liran Tal 02:25
Cool. Thanks, you guys for having me today. Glad to be back on this. 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 their frustrations and how we can help what is going on. Researching a lot of like 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. This is me at Snyk, but I have been up to a lot of things, since we last talked. It's like you just said, we're always trying to learn new things. I've been diving a lot deeper into the Cloud Native space, but the ops part of it. Things that used to be very reserved for like SisAdmins and ops before the orchestration engine and deployment and all of those things. But now, they're really at the hands of developers, I'm doing a lot of work there. We'll dive into it more, but there are things that have been happening recently, I have been around. We've launched this Snyk advisor thing, this is like six months back. But it's it's such a cool project that I'm so excited about because this is like, you could go Google the Snyk advisory, if you go to, it's kind of like this experience for booking.com but for open-source. 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? This is exactly what the advisor is, you throw in, or search for a specific package for you. At that point, we give you all of those metrics, based on that open-source package, 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. That has been very exciting. All of those things happening recently over here. How has it been about yourself? How's it going?
Chris Romeo 04:41
Oh, I think both Robert and I can say we are gainfully and happily employed because we know that the world of application security keeps needing everything that we can offer. That goes for all of us as an industry, but I know we want to talk about cloud-native today and how Cloud Native intersects with application security and a lot of those interesting details. But I think we got to start by, Liran, having you give us your perspective on what is Cloud Native. Because I feel it's one of those things that could mean different things to different people. It's like when I visit a company, and they're like, We do Agile, and I'm like, Oh, that's awesome. What does that mean? 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.
Liran Tal 05:36
It's a good start. To me, I think Cloud Native is 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. You operate; think about it in terms of you declare what you want in a declarative way, not in an imperative. You say I want three replicas of this function or this microservice, and you don't care what's going on behind the scenes. This is someone else's job and responsibility to figure this out. When you build Cloud Native applications, it means you need to think of those things; you need to think scale, of how do you adapt to those areas? If it's a function that you write, you think about it in terms of something very small, something very purposeful that you're writing. You do not care if this gets triggered with a scale of 100 hits a minute or 1000 because that is someone else's responsibility to care for you and elastically basically scale that up and down as needed. I think, as a developer, it has different meanings. For example, developers will think about Cloud Native in terms of, 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 so on. They think of streams and things like that. It is a concept change 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 do I think we'll want to dive into.
Robert Hurlbut 07:27
What's changing in Cloud Native space? I know it's been around for a while, but is there anything new in the latest updates that are out there?
Liran Tal 07:38
Yep. The adoption is going to grow and grow, we're seeing that all around, more people are using those Cloud Native related artifacts. There's so many examples, like if I go and get like an extreme situation, think about front-end developers in terms of Cloud Native, that is also like, what is the connection to relation that's Cloud, and front-end developers don't do this thing that you talk about in terms of, the bread and butter of Cloud, which is a little bit more often, or containers. But there's a lot there for front-end developers, for example, 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 front ends, and they're pushing some code, which is a back-end, but they don't think about it in terms of a back-end, but it's a function that they have direct, a myriad of functions, and then they think about it too much. Someone is responsible of that whole stack to do this, think about someone, a front end developer deploying a website, if they do it with Netlify or Vercel, they don't need to care about the SSL part, the edge. Now, how do you optimize? All of those things have gone beyond what we have done before, as front-end 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. 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. Beyond that, we do not care how that scales, we do care about how it scales, how it performed, but it's not our responsibility to operate it, this is someone else operating it for us.
Chris Romeo 09:36
In the model that you're thinking through here in a Cloud Native world, very clearly you've said that the developers, 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?
Liran Tal 09:57
Yeah, I'm trying to, with the extreme parts, 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 years to tune when we deployed something. Now, there is something that we declare what we want, and it just gets there, there is an entire infrastructure that that gets there. This is, I think, where security ties into it as well. If I take, for example, let's go back more natively backhand, like security related examples, and that would be, if I, they deployed a microservice in Node recently, and I don't worry too much about how that get orchestrated in the Cloud. If I wrap that in a function, or if I wrap that in a container, I just do it, I have my Docker file, and something gets it to deploy or whatever. But I think this is where security extends beyond what you used to think about until today to now more of it. So, if I'm a developer, you're talking to me about security, the first things that comes to my mind, there's my app security. So my code, my first-party code, what I actually write, if I'm thinking a little bit more deeper, I'll think about my dependencies, so the dependencies inside my code base, 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 stop thinking of how security trickles down to their app, and my Cloud Native vision to what security is for those developers, and this is what is changing. It's now more than this, its now extent because it's now their container image. When you talk about a container image, even then, at that point, people will say, Oh, of course, it's the dependencies in the container. Maybe I shouldn't bring in a very vulnerable base image, or maybe I shouldn't bring in app get install image magic because that might install a lot of vulnerabilities because image magic is very prone to those. But again, it's not just that. The container is also running and it's using a runtime. So the vulnerabilities are also in the runtime itself. Node can be vulnerable, maybe you're running an old version of Node that has vulnerabilities. It's not like out of support, it's just like an older one. Node releases every quarter, a security update. If you're not on top of it, it's not just a dependency, it's the Node runtime itself. It extends more because you're not operating a Kubernetes cluster, but as a developer, just like you have maybe until today wrote your Docker file, now you're writing this Kubernetes Yamo file. This whole infrastructure as code now definitely relates to you as a developer do this, you decide what is the replica set? Because you probably know, what are your kind of like functional or performance-related requirements from the application. This is a place where you can make a lot of mistakes, we're configuring, misconfiguration issues that we're seeing, untrusted unsecured s3 buckets or whatever. The change is, I'm not saying, the change is amazing in terms of, we're now understanding Kubernetes Yamo in all of this, this has been the step, and the adoption is going to grow more, but I think we're now looking at developers owning more of that, and relating more of that to their day-to-day job. That's what I think we're seeing more and more of.
Chris Romeo 13:33
So a developer first approach for everything? 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 the end product is going. You got to test it locally on your own machine. You have to replicate what's going to happen in production through your own local approach there. 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 promised we're going to focus on 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, can a large enterprise right now go we have decided we're 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?
Liran Tal 14:39
I think it's happening and it will probably happen whether we want it to or not, or obviously those I don't want to say like organizations or enterprises, but definitely those entities which will need a hybrid model and offline kind of things. You can think about governments and banking and so on. But there's simply a lot that we're gaining from putting things on the clouds that I don't think anyone is betting against that and thinking, Oh, no, we're gonna go back and manage our own data center. That's not a thing anymore.
Chris Romeo 15:15
Yeah. What about the threats? As I promised our audience, we're going to quickly make a turn back to application security. 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?
Liran Tal 15:33
Yeah, I think they are different, if you've been a pioneer of Cloud Native 10 years ago, you've been a pioneer that then that's what we did before, but as more people push into it, the threats are all around beyond what you're managing from the lens of a developer, it's just more beyond your own code in your AppSec. I think of it, as 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 was probably bigger before. But the moment that you have done that, and you as a developer, you're like, No, the whole movement of DevOps and Devs full stacking, owning their Docker files, or Kubernetes, and so on, you are now effectively, have increased the attack surface just because there is more there. It's anything from misconfigurations, to just the fact that there could be a vulnerable runtime, which may be in the past, who cares about who manages the run time that said, the SisAdmin, the the DevOps person, whatever the SR is, but now it's you, you write the Docker file as a developer. 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. They ended up figuring out a bit late into time when an update 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. Think about like a database, like a phone book, but then everyone can see everything else. There were two layers of mistakes that are misconfigurations that were done. First of all, was the fact that they didn't provide anyone the ability to register, it was a closed system. But the fact that they didn't expose didn't mean that the functionality existed on the bare bones of the authentication stack that Firebase provided. Anyone could register even though they didn't like expose it in any possible way. That's classic misconfiguration, where they didn't really do authorization. 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 that Yamo file. They just push it out and it was basically going through a tutorial or whatever. All of them basically have these rules of match document, reads basically everything, then allow read comma, write only to people who are not to anyone who can actually log in. But if anyone can register, at that point, it's done. This misconfiguration is what we need to help developers with finding those things for them because this is now becoming this, they didn't need to implement the authorization system. This is all based on Firebase, SMS, login, and all of those things. This is amazing. This is the serverless, the Cloud Native walls that they're benefiting from, but they still have to configure this, by the way, it's four lines of declaration of what they need to access that function. They've got it wrong, and they've realized this, a few months over and this was probably a few hundreds of 1000s of records during Sandy, like a real life reaction. This is what happened. So I think this is where we need to concentrate the effort weight like, explaining to developers where things could go wrong. These developer first approach of telling them where exactly we find the thing, the fact that IAC is now very kind of like OBICUS, it's everywhere, infrastructure as code we can also like refer to it and it's very now easy thing to also like relate it to developers because we can pinpoint line numbers, just like you were doing an IDE with a debugger or something. Tell them this line is incorrectly exposing authentication to a registration for everyone. Or you could say the same way. Like, if you're highlighting a Kubernetes Yamo file, you could say that Yamo declaration for the spot is showing that there is no, like you're missing out or restricting the user to be non-root or things like that. All of those things that we can just, it's really easy to relate that to developers, that's where I think this is going.
Chris Romeo 20:25
Yeah, sounds like you're gonna have more, it's gonna 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 the security misconfiguration issues. 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. As I'm hearing you talk about Cloud Native, I'm coming to this realization that 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 the same things that we had to consider when we started going to the Cloud, you know, 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. 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, whether it was a giant incident, and it was a result of the Cloud providers backdooring somebodies' running systems. I mean, there's certainly been offline, 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. That's where I'm landing when I think about the threat landscape, 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.
Liran Tal 22:08
Yeah, I agree. I think it's definitely right. It's not dramatically changing the threats themselves. But I think what is happening is, some threats simply become more obvious, they need to be more highlighted than before. Misconfiguration, its probably going to be in OWASP top 10 for the next addition or whatever, it's going to be highlighted more, and it's, well, how do you do lists, least privilege? How do you do that? Because I've done some call before an AWS and it's, I don't want to say scary. But there's a lot of Lego pieces that you need to tie in together. So developers, I know engineers making mistakes, it's not that uncommon, it's not surprising, its so many things to pull in together. It is obvious at some point, you're going to do some mistake, you're going to accidentally expose you know, Yamo role or an overprivileged function, which shouldn't be, it's going to happen, and it's going to be even harder because Cloud Native is very cheap. If you need another environment, just fire it up. Someone is paying for it. But that's it, it's easily scalable. 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 block access to it, how many 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 just exerts on that's how you get all of those data leaks and incidents. What happens is you have this OWASP Top 10 for serverless. It's just highlighting specific threats that are more, it's like web risk that you will be more prone to make those mistakes and that's what we want to help you remediate first. This is the whole story.
Robert Hurlbut 24:13
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 that role change in some ways, but still the same? Are there some good recommendations or thoughts on helping a developer make some switches there if they're now going to focus on Cloud Native apps?
Liran Tal 24:52
It's a great question. I definitely don't have the silver lining answer for that one or the silver bullet for that. It's a change that I think for 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 50% of the solution. That is definitely there, I think the more that will create, like tooling, like an IDE tool that an extension, just like developers add extensions to colo their brackets, ending and closing or whatever, we could give them tools. As they write, if they wrote something, a Docker file that does from Node, colon latest, at that point we'll tell them, no, don't do it. 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 those vulnerabilities, or maybe it was a digest, because you don't want to always pull latest versions of packet of images, because that's not an atomic operation. You want to get always the same reproducible builds. 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 over an SN engagements, get their heads around this. Ultimately, some of the answer exists in the question that you asked, and you give the examples of how do we get developers to think about authorization in different ways. I'm seeing more developers today not trying to roll they're on authentication. I'm not seeing people asking me, how do I store passwords? That has been a thing, if you remember the net, 10-15 years ago, Stack Overflow of 2004, that has been the question. How do you manage passwords? How do you do password reset? How do you do Forgot Password? You do not ask those questions today as a developer. Because you're using this serverless, Cloud Native constructs that help you build authentication authorization, you offload it to Okta, or zero, all of those things that help you do it, because you understand that they have solved the problem, and you need to get your app working in that function. That's what I'm saying, that this mindset exists, we just need to highlight more of the issues that you might be making and telling to be careful in these areas.
Chris Romeo 27:25
Yeah, you talked about IDE plugins, you talked about potentially some other tools and things. 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? When I think AppSec, I go right back to the secure development lifecycle and I think, from requirements to threat modeling all the way to incident response at the end of the day, are these pieces just the same? Are there other things that are unique in a Cloud Native environment?
Liran Tal 28:04
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'm hearing this a lot. When you do an npm-install, you're getting 50 vulnerabilities at that point. There's a vulnerability fatigue. Because, at that point, what exactly should I do with this? That's where I'm thinking we need to, first of all, provide, you know, real valuable data on what you're saying with like, least false positives and things like that. But also prioritizing it. An idea for how you would prioritize it is that old model of CVSS scoring, telling you if a CVSS score of vulnerability has a score of 10. Then you you say, well stop everything, let's go fix it. That may not be working anymore because there's 100 vulnerabilities. So what do you do at that point? You need to start somewhere. 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's so many metrics or indicators that you need to build into a vulnerability once you get it, once you're exposed to it, and that would be for example, well maybe there's a high vulnerability. It's high, it's getting like nine or whatever. Then there's like a medium vulnerability, a CVSS score of six or something. Which one would you do first? It's usually the 10. You say, let's move on to high vulnerabilities. But what if the indicators behind those vulnerabilities were actually this? The high vulnerability is maybe for like 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 for like SCA. For libraries, you need to explore maybe there's like an alternative package you could switch to or whatever, like rollback, you start doing this. What if it doesn't have any like POC exploit for it? All of those things that, say that this is high vulnerability, but it's not really that urgent to fix, whereas that medium vulnerability is for a production dependency, and it has, hey, there's like, it's like an index access, to somewhere, but there's an exploit for this in the wild, there's a POC somewhere in like Metasploit that someone could weaponize against you. There's also an upgrade for that specific version that is vulnerable. Basically, remediating that vulnerability is both more urgent and more easier. That's why CVSS doesn't scale and prioritizing vulnerabilities in a different way, that scales more. This is like an example from SCA from just working with composition analysis, open-source packages. It applies to the Cloud Native world the same way, if you have a Kubernetes cluster, that you're running with some podes, maybe there's like an misconfigured Kubernetes that has containers with vulnerabilities, you probably want to remediate that faster than some Kubernetes worker node that has a lot of vulnerabilities, but nothing is misconfigured. It still is privileged, 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, deeper and so on. I think that's kind of where it's gonna go.
Chris Romeo 31:49
It's a change in priority, then, based on what you're saying. I gotta say, I love your perspective on this, I can just hear the developer-first security thought process that you're sharing with us here. 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? We can be coaches and advisors, but it's not like we're the people that oh, well, that has to come through us. In the world you're describing, that's no longer an even an option in this world. I think that's a really neat way that you're approaching this I know, Snyk is approaching that from that same perspective as well. 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 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. A lot of it goes into the newsletter, our Hi/5 newsletter that we send out once a week, if I see something from Liran, it's like, oh, yeah, that's going on my list. Tell us a little bit about that project and what, we as developers, can get out of that.
Liran Tal 33:08
Yep. It's an interesting one because it started with thinking about, maybe I should write something about how we build containers, in a safe way, build a container image for Node application, but that's where I'm from. But do it in a sane way. Now, the thing is, I've Googled some of these myself to see what others are focusing on. There's so many examples of wrong, people are missing in the tutorials a lot of like, wrong practices. They will tell you no use from Node latest, none will say, no change to a user least privilege. Or maybe they will say if you need to put a secret in the container image to just like an arguments that you pass in, or put it in the Dockerfile or whatever, something more. So, I've just seen so many examples of this. This whole idea started with I was like tweeting out and I was saying, I've seen a lot of these issues in tutorials and how we educate the community around it, would anyone be interested in learning how you do this, its like 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. That's what kind of motivated me to do this. I did this one a bit different. This is like a cheat sheet and 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, we're starting off with this base, I think four or five lines of code of a Docker file. It's super simple. From node, copy whatever you need npm-install, command npm start that's it, like the super simple example which by the way, some tutorials also like stopped there. They introduce you to Docker and then they leave you with that one to go off with. Then I go on, one by one, like, why is that from an issue? What can go wrong with the copy? Why you need multistage builds? How you do secrets properly? What has been going there for like, we're talking about cloud native, what has been the one thing that I haven't seen in any tutorial that I've read was that people start those Nodes containers, just saying, CMD, the command node starts or npm start, and they're both wrong. Because if you're running this container in the development and run it on Docker, that's fine. That will work, but in a cloud native world, again, like 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 summaries, it scales down or whatever. If you use any of those variations, none of them will cleanly kill the process. That's why you actually need to work with expose, like an init system inside a container that works with it because the containers do not usually, like you know, what the state the healthy thing is not to actually let them be no process ID one, because the kernel itself, treats them differently. Even that one little piece of information could make miracles to your production environment because it could have a healthier ecosystem in your cluster, rather than zombie processes running and lying around. I love this work on the Docker containers because it just showed me 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, and probably will do more around this topic. This has been a fun one for me.
Robert Hurlbut 36:53
That really sounds like and I was thinking this, as we were talking earlier, that in terms of that shift for developers is, oh, wow, I build everything locally, I know how it works locally, I just push it to the Cloud. I don't have to do anything, it just works. That's not always the case, there are going to be differences. They need to be aware, developers need to be aware of those differences as they're building. Whenever we build a Dev, send it to staging, send it to production, there are going to be some differences. You have to be aware of those, similar here. You try to do as much as you can to make them similar so that you're not getting yourself into trouble. But it does sound like it's another world and so things that you need to think about.
Liran Tal 37:43
You are opening that door for me for my other passion, which is around like software testing, and I have Yoni Goldberg is a curator around the biggest node best practices and GitHub and so on. He's also worked on this one with with the node practices. We always tease each other because between doing unit tests, and doing end-to-end tests what's more important? What should you do more of? You're banging on that door of maybe I should not even have a staging environment, maybe you have production, that's everything in production in that state. I don't know, maybe that's the way to do it. There's just so much thought process that you need to pull into software to build it right. When you do it lately, it's costly, you end up doing rewrites or whatever, when you have security issues, it's also costly because it's incidents and whatnot. It's testing all of these things, everything just connects together.
Chris Romeo 38:41
What, Liran, 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.
Liran Tal 38:56
Homework, I like that. That preference to the 10 best practices or something like that about containerizing the Node apps with Docker is a great start. If anyone needs to do it, that's already a great guide. 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. 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 threat modeling with yourself. What could go wrong? That example, again, from like a colleague or friend they have about that Firebase, that's a real world example of that being exposed outside as an incident, a security incident, again, that was like four or five lines of configuration of a file. The mistake there would have been disasterous. Asking yourself, I'm doing something, but now what is the meaning of putting you know, Asterix, Asterix something or what is the Cloud doing with that data behind the scenes in terms of, how does it operate? That is super important because you know what you're configuring this, you think, you know, but maybe the under, if you look from above, there's something that happens there that creates this and make different decisions, and comes to different conclusions based on what you provided. Your input is not very comprehensive. It's the same story all the time, you miss out on some Docker file directives, then you missed out on security, you miss out on Kubernetes security capabilities or whatever, then you're missing out on security. I would say, have that mindset to think, What am I probably doing wrong? The moment you'll ask it, you'll probably start asking the development people or Google or whatever, and you'll figure out what you need to fix it. So having that mindset.
Chris Romeo 40:55
Yeah, that's very helpful. Cloud Native and security, what could go wrong? Liran, 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. Thanks for helping to give that back to the industry so that people can create better containers. It's good for all of us when the applications that are running out there are more secure. 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. Thank you very much.
Liran Tal 41:30
Thank you Chris and Robert, thank you for having me.
Chris Romeo 41:34
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.