 Thank you. Hi, everyone, welcome to this session. My name is Lirantal, also known as the guy with the yoda hat. And I'm a developer advocate at Sneak on a mission to help developers build applications securely using open source. Actively working with Node.js or the OpenJS foundation on the ecosystem security working group to help improve the state of security for open source. Node.js and NPM JavaScript as a whole ecosystem. I'm involved in other application security projects. So you're welcome to follow me on Twitter or visit my blogs on the Sneak website if you have any questions or want some references. And we are going to go off. And I'd like to open up with this following questions to ponder upon. And that is, are we going to have less or more software in the future? Are we going to use less or more open source software in the future? So to answer these questions, we need to take an underlook at how software is being constructed these days. At the very core of the applications we're building, there lies our own custom applications code. This is the top of the iceberg above the water. This is the code that we, as developers, can very clearly see day to day. It's what our colleagues write. It's what our IDE is and what is on our focus and state of mind all the time. So looking at these code snippets, can you find a security issue? It brings up the question, are you aware of the security issues in your code? As you look at the following expressed middleware, as is common in Node.js application, what actually is hidden there? And there is a security issue here, but we'll get back to it later. So there is the open source code that has been there with us for many, many years beyond just our own code. This is the open source code that lies beneath the iceberg. And we may not think about it too much in our day to day coding activities because maybe some of it is abstracted away and we may not be even aware of the libraries that we use, but it really makes up the majority of the code that we write. Up to 90% of these open source software and libraries that make up today's code in different ecosystems like NPM and Ruby and Maiden. And most of the time when we find vulnerabilities, we find them in open source packages that are coming from transitive dependencies. So this is a whole new complicated world which we'll dive into as well. But really now on open source packages, let's take a look at this code snippet from this popular open source library that you might have used at one point in time in your Node.js application. Can you spot the code injection vulnerability that hides here? Once those vulnerabilities become publicly known, the first thing you want to do is, well, know about them, right? So you could then take actions like upgrade to a fixed version or maybe patch them, apply a patch if there's no upgrade fix. Maybe you want to migrate away to a different library if needed. So here's a mental exercise summing up a little bit of these open source roles. Imagine you're building an app, this could be a Node.js app or something else. Your mental image of your application is focused on the own code, what you write. You dwell about it, you spend hours debugging it, you're refactoring it and testing it, right? This is something that is very much the application core of what you're building. But really the reality is a little bit different. This is the mental exercise here, that the code that we're actually building for this application is actually significantly smaller than the mental image that you have of the application itself because the application you're building is actually relying on a lot of community-powered codes and we're leveraging this beautiful open source world which boosts our productivity, but need to be aware of what's going on there. So to put this in more perspective, we shouldn't be surprised that our applications today may have security vulnerabilities, right? We are containerizing them to our serverless functions, bare bones, easy to installs, so many ways that we can bundle open source dependencies here and there and therefore lies the risk. So the use of open source is accelerating as we're seeing, but the adoption of that, the great adoption of that comes with great responsibility and risk as well. So we're seeing continuous growth of vulnerabilities in open source software in different languages and this is growing along with the growth of open source in general. And as users of this, we need to be, we need to have the ability to mitigate them. We need to be, we are maybe owning them in a way we are maintaining or using open source software and this is a viable risk. Now taking a step even deeper into this world of open source software, there is the question and the topic open source supply chain security. And I wanna share an article that was published, not so long ago, October, 2020. So very recently by a government, right? By the United States of America, the cyberspace solarium commission that was really advancing and then promoting the notion of potential compromises, right? From supply chain security. And actually it calls for establishing a center for open source software security within government organizations. So I will give you one paragraph that I paraphrased out of this article which I recommend reading and that is dependency on adversary countries for some or most of our critical software supply chains threatens to undermine the trustworthiness of critical technologies and components that constitute and connect to the cyberspace. As you can see, there is a lot of awareness in terms of what could actually be coming out of open source supply chain registries and things like that. And that is why this is catching the attention of governments worldwide along with companies and everyone else relying on open source. This is basically a testament and acceptance of us. And evidently, we've seen these security incidents happen time after time. For example, on the NPM ecosystem, we've seen a social engineering attack and a malicious incident for this package called the event stream that was downloaded millions of times a week. And it demonstrated how deep the attack surface that was aggravated and by security concerns, it nested dependencies because someone were able to socially engineer a way into injecting a malicious package into this popular package that was downloaded millions of time. But we have to ask ourselves, have we learned nothing? Because a year after event stream, another incident took place, this electron native notify package which targeted still in cryptocurrency, the same as it was with event stream. It targeted this stealing of cryptocurrency from users who are using the Commodus Agama wallet. And it really went through the same process. So what was going on there, right? A dependency was added to a library. Three weeks later, that dependency publishes a new version with malicious payload. And three weeks after that, the Agama wallet software is rebuilt and pushed using a recent version of an electronic notify which now includes the malicious version. So this is how software trickles down from supply chain into the end users to like the build process and development and everything else. And if that software is compromised at any point of those stages, that is a whole story of open source supply chain security. So another example, this is this word package name is one out of three packages that existed on the NPM repository for actually more than a year before someone found out about it. And it targeted a complete system compromise as you could see from the NPM staff announcement when this was found. So living aside even the supply chain security, there are different aspects of security vulnerabilities. For example, those that are unrelated to malicious incidents that we all need to be aware of. For example, a UI library called Frappercharts from 2020 having an access as a cross-site scripting vulnerability in this front end charting library. Maybe a universal library like URIJS, which has use cases for both front end and back end needs but it is suffering from validation issues. So you may not be using it in a correct way or there is an upgraded fix that you could use to have the safer version. EJS, a popular no-JS templating library that is still vulnerable if you're using 3.1.5 version of that which has a high severity code injection issue. All of those which you should be very well aware of if you're using open source software. The thing is with open source, we need to do a bit of due diligence to find out specific things about open source packages. So this advisor website that you could use gives you this sort of health metrics around popularity and maintenance and security considerations and community. So you could evaluate if you wanna use a new package or an existing one and you have second thoughts or you wanna check what is the, if you should move to a different alternative or similar package, what are the options of doing that and are they actually doing any better? So we have all of these tools but really understanding our dependency trees is a complicated task. Even more complicated at times is the ability to tell where vulnerability originates and how to fix it. So as an example in the JavaScript ecosystem more than 80% of vulnerabilities that sneak users find are in indirect dependencies. It means that even if we are looking and watching at change logs and everything around the direct dependency the express of the world what is happening is most of the time when we find vulnerabilities they will actually manifest in those indirect dependencies those transitive dependencies that the direct ones simply bringing in which is hard to track because then we have a bigger dependency tree. So nowadays at the very least we have bots automated bots that help us stay on top of security vulnerabilities whether you're getting those automated pull requests from sneak or GitHub or somewhere else that is great that you are knowing about us but really what is it telling us is this is a message where we are entering a world where security is turned on by default is something we are now used to. Secondly tools basically adapt themselves to a developer's mindset not the other way around. And this is an entire mind shift of how developer security is actually and developer first security tooling is actually changing the way that we interact with software. So developers, if we sum it up developers often think about the security of their application in terms of vulnerabilities that play in their code or in their open source dependencies and your open source dependency footprint is a great way to start to improve your application's security posture because as we've said open source components make up to 90% of your code base but really what lies beyond that point, right? Beginning with security in open source dependencies is a great start as we said but we are transitioning into this cloud native world where your application is really more than your code. And what I mean by that is when we build cloud native applications as developers our application stack surface is more than just the base of the application code. Still, right? What is that actually mean in practice? So I wanna explore that with you. Let's say you consistently scan your project repositories for security vulnerabilities. You are now aware of security vulnerabilities coming from your code and from your open source dependencies. So you audited your dependencies and once you fixed things how do you know if you're not vulnerable to a new vulnerability that was released after you last scanned it? So what you actually need to do is not just scan it as a one time off but you actually need to monitor the project because you may have scanned it at one point but then new vulnerabilities are keep coming up and are you monitoring that project all the time to get those alerts? So you've done that but now you have a baseline of the vulnerabilities that you have. So as the next step, hopefully you even got to a really, really good baseline point where you have maybe a few or even zero vulnerabilities in your projects. I want to say congratulations, amazing job which it is but there's a bit of a misconception here and that is what I wanna highlight specifically in this talk and that is our application repository is continuously scanned for vulnerable dependencies. This is great but it is not the complete picture. It is not capturing the whole story. There's the issue of potential dependency parity drift which are deployed artifacts. And that is right. It means that we don't just develop applications to build them and save them in the repository's main branch. We also deploy them and there could be a drift of different states between the dependencies in the deployed states and dependencies in the main repository branch. And that is the drift that I'm talking about here. So this is where the next layer of our story actually reveals itself. In a pre-cloud world, we deployed on bare metal servers. We deployed on maintaining our own infrastructure. We had hopefully achieving elasticity and some flexibility with virtual machines but these days, who even remembers those days or care about the overhead of maintaining your own infrastructure because we have entered into a cloud era, right? This says we are living it. We're not just entered. We are the fact out there. So it means that if you build a small API, maybe you go ahead and deploy it as a serverless Lambda function. If you build a frontend, you may deploy it on a Netlify or Verso as cloud frontend infrastructure and they worry about all the SSL and the caching and the edge deployment and the atomic deploys. You give them that concern and they manage that for you. This is the cloud. If you maintain several microservices, it's natural to fill the way, the urge to wrap them up in a container and deploy them to the cloud, right? And let's focus on that specific part. This is the whole cloud native part. This is containers, for example, as one of those example that I've said before are an easy topic to talk about because we can easily relate to that. It gives us cross a platform compatibility to deploy no matter what cloud you're running on. It is faster and more lightweight to spin up those than VMs. It provides you this reproducible application environment. So for all of those reasons, we could talk about containers. So let's dive deep into this and now try to fill those blacks. We talked before about all our application dependencies and our application dependencies are not running in a vacuum, right? They are part of somewhere. This gets deployed somewhere. Don't just write code for the sake of writing code. And so now this black space, I think it becomes clearer because if we're sticking to these examples of Docker containers here, an application that we containerize as a Docker application, for example, this Node.js application, suddenly tells us how our attack surface grows in ways that I'm sure you may have not thought about before. So let's break it down and see what attack surface is now being more of a concern for us as developers. For example, this is a Docker file which I can go ahead and show you how we actually have a Docker file for a Node application and what actually hides in it. So what are we actually bringing in this Node.js image? If I'm bringing in, if I'm saying from Node, and there are different bad practices here, right? So this is just for the sake of simplicity and brevity kind of small. But what, if I'm doing from Node, what OS dependencies am I bringing pulling into my dependency, into my application? And do I need all of them? You may need some specific tools and libraries available on the container for the application to function properly. So maybe you want to convert images. So maybe you do up to get install image magic because you choose to spawn a system command that uses image magic library that is available on Linux distributions, like Node is based on Ubuntu or Debian. So this common software makes up your container and well, potentially it increases your application attack surface. Now, I understand that at this point, maybe it seems like, well, how do you connect the dots between a vulnerability that someone is able to exploit from the other side of the application into a dependency that is running on the container itself that could be vulnerable. Well, I'm going to show you how we do it in a live hacking session quite soon. I'm going to go see all of these unfolds. But more in this Docker file, what lies in there, right? The version of the dependencies in deployed containers can be significantly different from what you have even scanned and monitoring your repository because deployment doesn't necessarily mean that it is the same thing that you had in your repository because of the drifts. So if you're not installing dependencies in the same time and you're not fixing them and you're not pushing those security fixes, right on time, you may have those disparity drifts. But really the thing that I think people are missing a lot in terms of understanding the containers, the container side of vulnerabilities is not the actual vulnerabilities in the container itself, but actually the runtime. What are you doing from node, right? Which version are you actually pulling in? Do you know which version are actually running in production? Do you know if it is vulnerable or not? Because this is the node runtime. This is what people have direct interaction from the outside of the application to the node application itself that you've built. So it's meant that if there's a vulnerability in the node.js runtime, well, that is directly impacting your application and node.js vulnerabilities do happen time to time. So you need to be aware of this. Now, there's a good reason we're talking about containers here as an example because this race to the cloud that we also often referred as this digital transformation has accelerated the use of container technology. And what it means is that this problem space of using safe base images isn't very intuitive for us to figure out. So what is happening as an example here is we are consistently, year after year at Snakeware, we've seen that the top 10 Docker base images on Docker Hub are carrying security vulnerabilities in them by default. So just by using the default node base image, you're actually introducing, you know, 500 or 600 vulnerabilities, maybe more, maybe less. And this is just by getting that from node image. So let's hack an application, right? Let's go into this live session where I will take you through a process of how we're exploiting an open source library called the marked, which is a markdown library that I used to build an application, a to-do application. You can see kind of like how it is used between the application logic and how it is used in the view to render data. And we're gonna take even a step further. We're gonna hack an application based on the fact that we have a vulnerable dependency in it, specifically image magic as a way to convert images on the container itself on the application. Even more, I'm gonna show you how we are able to hack into an application based on a vulnerability that exists in a node version in a node.js runtime itself. So hopefully you're ready for that. And I'll be happy to have that session run as like an interactive one. So if you wanted to take part, if you wanted to ask questions, if you wanted to engage, I'll be asking here and there for you some hints. Go ahead and use the Q&A box to just submit some questions for us. And I'll be trying to do the live hack and monitor that at the same time. And we'll be able to have a bit of an interactive session here. So to get us started, what I'll do first is run the app. So for that, we need to run MongoDB as the database for the application. It's a lot of logs which we don't care about, but we go here and let me know that the database is running fine. I'll be running the app. It's available on port 3,001. So we could go there. There we go. And we have the app running. So as I said, this is basically now for us way to start investigating what is wrong with this application because it has a vulnerability in it that has a dependency that has a vulnerability in it. So this is, you know, we could say, you know, hi Linux foundation folks, right? And it has marked which is a marked down library. So I've started here before in this advisor thing, which gives me a really good health score, you know, a hundred or a hundred. This is pretty great. So pretty perfect. Anyway, this is five, almost five million weekly downloads. This is getting, you know, really great numbers. So I'll use this. It looks, you know, very maintained, very healthy. And this is what I'll use. And I've already added this to our project. So you can see here, I have required that in the top in my require file. And then we have marked set option sanitize true. So this is interesting from different perspective. First of all, if I hadn't done that, what it meant is if I hadn't initialized like marked with any specific sanitize or other options, what would happen is it would actually initialize in an unsafe manner. So at this point, I am going to, you know, put all the security gates that I can in here. You know, this is where I'm exposing it to the view. And, you know, later on it is showing up there. So it could be things like maybe we want to add links. Like this isn't good examples of markdown, right? You can do something like this. And there we go. We have markdown turned into a link. So this is the capability that we wanted to get from this markdown library, which is of course I'm not going to use, you know, write my own markdown parser. So I have this and this is like the greatness of open source. Next, I will try to exploit it. So any ideas on what we could try next to maybe exploit this vulnerability? Would you maybe try something like this as one hint? And as I said, you could feel, you know, you could feel engaged to just put something in the Q&A. If I try that, what do you think will this work? That's right. Well, it didn't work. It's not working because we're sanitizing. Remember we said we're going to sanitize all this input that we're getting. So marked has this logic that anything that it gets, it's gonna try to sanitize it away. So this didn't really work too well. I can try something else. For example, I know that through links, I can also add JavaScript. So I could try something like this. Let's see if this works, JavaScript alert. Okay, so this is almost there. We're trying to create an XSS across I scripting vulnerability here based on the fact that maybe the marked library that we're using is vulnerable. This doesn't work. And there's a reason why it isn't working because of the fact that there are regexes inside the marked source code that remember we said sanitize through. So it's looking at all of those, you know, things that we're trying like JavaScript call on something and it's, you know, sanitizing them away. And I've got this great answer here from David Acosta. Thank you. I can try HTML encoded characters, which means I can, if it's looking for JavaScript call on something like any function that goes from it, I can represent colon in a different way. And these are called HTML entities. So I can do something like this. And 41 is the closing here. And I can try and represent stuff that I know, you know, maybe looking at the source code of marked, I know that they need to escape from them. So let's try that and see what happens. Almost, almost. This is a great direction, David. Thank you. So for us, what it means is it's not really game over because we can still try more things, right? Marked is open source. I can see what the actual regex is trying to look at. And I know there's another regex because it looks for HTML entities. So like the maintainers were thinking about this and they had like great security mindset here, which is amazing. So this is great, but what's actually missing what is what kind of like, you know, the security bug here, the vulnerability that manifests is if I'm gonna represent and I'm gonna make a slight changer to the HTML entity, I'm gonna use this document or even like this as like a JavaScript, you know, this is a valid JavaScript keyword, right? If I use that, this doesn't make sense as, you know, the whole string here doesn't make sense as an HTML entity. So it passes the sanitization process and that is where the flow is at. So it passes it and this, you know, mark says, you know, this is fine, whatever you want with it, put it on the screen, but the browser treats it as a different way. Maybe the browser allows this to actually execute JavaScript. So let's try it. Well, first of all, we're seeing to remind you like this is what we've just added. And you can see that now we have a link. And if I click on it, then at this point we have basically had this, you know, established our exercises. This is a cross-site scripting vulnerability that happens in marketing and open source library, having millions of downloads. And this version that I'm using that I know is vulnerable for this, you know, demonstration purposes, but it is a real vulnerability in an open source package. And this exploit for it is live. Now, there's an interesting, you know, story here between this library, which is why I like, you know, repeating on this specific vulnerability because there's a story of open source here. And, you know, let's go through this. So if I go into my vulnerability database, you know, over here and I, let me filter this for NPM and I'll go ahead and do more. I wanna search for this one specifically. See, it had over the times, you know, different kind of 2020 and, you know, I think I said something on 2021 as well last time. Yeah, so even in 2021, not so long ago, different kind of vulnerabilities that we know we should be aware of. But this one specifically, which was, you know, fairly a few years back was discovered by Matt Austin. And I wanna show you what happens to her because the way that it was discovered is, they opened this open source pull request to this repository, you know, saying there is an exercise with no vulnerability here and there's like a great report. And, you know, people are thumbs up, right? Because this is a pull request, it's not just an issue telling, you know, annoying the maintainer, you know, hey, there's an issue, fix it. This is really helpful. This is for me as a maintainer, I wanna merge this, right? This is it has tests and really like for regression testing and it has the fix itself as well, like everything is here for me just to go ahead and fix it. But as is with open source, right? Maintainers have their own lives and we can't expect them to hold them accountable for all of those things. And this is part of the open source story where maybe a pull request gets open in 2015, but yet only got merged or released to production. Even if it's a security issue, you know, a year later, and this is the problem, right? So there are ways to, you know, what do you do when you have this problem, right? What do you do when you cannot upgrade a library? There's like no upgrade for this library at, you know, war at that point in time. So Snake has this cool stuff, like, you know, there's a patch and all of this is like freely available. You could, you know, you could just, you know, view it and use it and then the whole sneak building if you didn't want to, but we make it available. So this is for you now a patch that we take and you could just, you know, run like a sneak CLI command, sneak patch. And if you have this, it will go ahead and apply that patch if there's no, no upgrade fix. So this is a great story of like how open source connects how, you know, you need to be on the bleeding edge. Sometimes there are no upgradeable fixes, which is, you know, a whole story of itself, but this is the story. So hope you were having fun. Let's, let's, let's take this app aside, you know, and say, you know, hey, let's, this is running, you know, on my dev machine, you know, this is just npm run start on my dev machine. Let's go ahead and do run something in a container. And, you know, if we had bundled in an application container, what could go wrong? So I'll go ahead and stop here. My mom going to be, I'll go ahead, stop the app. I said that it stopped and I've got some slides of screens ready here. So I will start with, first of all, as we need to do first build a container, but I want to show you first what is going on there. So as we go over here, we can see the actual container itself. So this is my app. It's a very small application. The whole thing that it does, this note app that I deployed to production on a containerized instance is I want to convert an image. So I have this upload route that all of the app is exposed from this slash public route as well. And what I'm going to do is I'm going to spawn a command because I do not want to block the threads for the Node.js application to do anything like no synchronous here. So I'm going to use this convert application that is built and available as image magic is on my container. And then, you know, just go ahead and resize the image. This is my Docker file. It's pretty straight. I didn't even have to install image magic. This is just apparently it's available in this Node image. And yeah, we're taking now, you know, the time train we're traveling back in time back to where Node 6 were alive. And if you think about it, if you were running Node applications back then as well, you know what could have happened. So this is just picking, you know, some, you know, some node image tag here. And all of this is, you know, pretty, pretty simple. So I'll go ahead and do Docker build, which I've done before, but it's always great to see that this is up to date. And then I want to run this application. So I've got this one different for there we go. So this is going to run in this port and I call it RCE. You know what, when RCE that should give you a hint of like what is going to go on here. So let's, let's leave this up and move into this one. Okay. So a new application, as I said, everything exists on slash public. So I will open that. And as you can see, this is allowing us, you know, tell odor, upload an image to convert this. So I can go ahead and upload the conversion of images. So maybe I'll go ahead and choose one. And I've got a few of them ready. So hopefully you've uploaded something to social media. I have something called RCE1.jpeg. I mean, that's just fine or it should be fine, right? But before I do that, I want to go into the container itself and tell you why that might be an issue. So let's go in and see. First of all, I will find my running container here and see RCE1 and connect it. And at this point on this side of the screen, I want to show you the files that actually this is deployed in user source Goof. Remember that's what we had over here, user source Goof. This is the place where we deploy the application on. This is the working directory on the container itself on the OS. And these are the files that exist in it. This is, you know, what I showed you before, the server.js, everything there, even the Docker file is there. This is not a best practice, but this is great for our demo purposes. So I have it here. And what I want to do is resize this picture, which is, you know, makes sense as, you know, maybe if you want to build. So it looks like it's over, it looks like it's done and we have resized our applications. But what is going on? Let me show you a difference here. So as you can see on the right side here, my directory here is a little bit changed in terms of outputs of what you see here. Specifically, what I want to call out is there's this new file called RCE1 that was created on the running container, which did not exist before, as you can see on the top of it. Now, why did that happen? This is because we have an exploit. Oh, there you go. I'm already on the exploit directory and I will cut RCE1 and show you what's going on there. So essentially what we have is you probably, you know, haven't seen this one before. It's not a very common way to create JPEG files, but it is supported. It is a way that ImageMagic is a library, like I said, a tooling for, you know, for Linux to basically allow you to manipulate images in different ways. It has this feature called Delegate where you could have not binary data, but declarative text data that tells you how to build the image, tells the ImageMagic library how to create an image. You know, define the resolution, you say, you know, fill the image based on this other source, which you could, you actually can provide it this URL source to do it, you know, over the wire or something. But what it has is a vulnerability that does not check, does not validate that this could be, because this is offloaded to another command that ImageMagic spawns, it doesn't validate that this is a specific, you know, URL and not something else. But what it does is it takes that, you know, we take, it exploits that vulnerability and actually appends to it or adds to it this command execution that is touch RCE1. Touch is a Unix command that creates a file called RCE1. And that's why we have it here with the size of zero because we just touched it. We just created nothing else except that. But by the fact that we were running a vulnerable version of a dependency in a container, right? This is nothing to do with the application itself. The fact that we had a vulnerable version of a container here of a dependency there, ImageMagic, you wouldn't know about it at all if you've seen this one. This had introduced a vulnerability here that we have exploited. And, you know, the code here, there's no issue with the dependencies here. There's no issue with like, you know, code security issues here that allowed that to happen. This is just a fact that we have relied on a specific dependency in a vulnerable container. Now, how do you manage all of those things? So if we were talking about, you know, scanning your applications, right? This is the, you know, me scanning this Goof application that I showed you before and this is the dependencies, right? So I can see the dependency tree. I can look at, you know, all the dependencies remediation. And I can see that to marked is, you know, having vulnerabilities in it. I can go ahead and fix this. If I do it, you know, get this automatic pull request that fixes it. If I don't, you know, if you just set it up to just fix those dependencies. But this is a great way of understanding your dependency tree and all the problems that happen from it, you know, but even more interestingly is, you know, the ability to know how to remediate this problem from, you know, what do you need to upgrade and what problems does it solve? The other thing is the container side, right? We've, we're running node six, right, a specific base image of it, which has 800 vulnerabilities. Again, if I look for image magic, that's here. So what do I do with all of those? I know, what is it like? Hundreds of vulnerabilities in image magic. How do I know what to move into? So maybe something gives me an advice what to move into, but I'll get to that in a second because I showed you how we can do it from the app side and the container side, but actually want to take it a little bit further. I want to talk about what happens when the node runtime is problematic. So what I mean by problematic is, you know, vulnerable. So for us to make that happen, what we need to do is first of all build the container. So let's say you know that now node six is vulnerable. So I'll go out of this and I'll first of all start, I'll stop my containers, my container is running here. There we go. All stopped. And I will go ahead now and say, hey, you know, this is, remember this is us back in time, back in the days where there was node six and maybe you had that running in some microservice and you're saying, well, you know, now this is have like a new version, like the new LTS is eight, right? Let's use node eight. Let's use node eight, zero five. That's like the newest. That's like the latest version of the stable. It has all the fixes, everything in it. Maybe, maybe it doesn't, I don't know, but you could have made that decision to move from node six to node eight, five, zero. Let's see what happens when we do that. So I will go ahead and need to now rebuild this, this is the same app we're going to rebuild it. So Docker build, there we go. Yep, done. So once we've rebuilt it, the Docker image, now we can go ahead and run it. I'm going to do the same thing as we've done before. So it's the same app. Let's see if this works. Okay, this is the same app and you know, it now doesn't really have the other vulnerability of image magic because we have used a new version of image magic in that, you know, node eight, five, zero. So we have migrated out of one vulnerability, but what happens with a node runtime itself, which is another concern that you should have. So if you're using slash public, maybe you want to try different ways of, you know, run times have issues. Some of them could be, you know, redos attacks or, you know, just denial of services of different kinds or maybe, you know, HTTPS related issues and, you know, leaking of information and things like that, like memory issues and stuff that have been also hitting nodes in the past. One of the other things could be a batch reversal that maybe the runtime is not managing that correctly. So what we could actually do here is, you know, try and traverse this tree like that, which as you can see, doesn't really work too well if I do it from here. But if you have any idea how I can do it from here, you see my question box to you. Okay, go ahead and suggest, but I'll just go run into it with this in the meanwhile. And that is maybe I want to go ahead and try something similar to what we did with Mark, which is I'll go ahead and URL encode those dots. So a dot is the 2% key. So 2% key. And you can see I've already like tried this a while ago and this is basically the way for me to traverse the tree of the directories back inside as if this was running inside of the container itself. So the container has the slash public as the root directory, but we want to traverse far out of it because we want to see the package JSON. We want to see the dot end file that you may have API keys. We want to see different things that might be telling us as attackers for this might be telling us more information of how we could hack in. So the way that we're doing it is we're basically, 2% to 2% here we're now traversing up the tree. We're using a bit of a logic magic here to exploit the vulnerability related to patch reversal in the Node.js runtime. And if I run it, this is basically now the output of the ETC password of the running container of the inside like this node application. So this is nothing to do with dependencies on the container. This has nothing to do with my code being bad like over here, nothing to do with this. I've basically just created a public route here with express and known framework for Node.js. But I am taking advantage of exploiting a vulnerability in the Node.js runtime. So this is the case of traversing from the top to the bottom. And I want to go back into our slides and continue this story. So hopefully that was fun, right? But what can I do about it? And I'm pretty sure that this is kind of like, what could I do with this? But first of all, I want to give you a bit of like references here. So what we've exploited on the container side was this improper input validation, CVE vulnerability report that came out for image magic. And this is very, very real. But it is also very easy to miss as a problem. First of all, the CVSS score is not like a 10, right? Which is shouting. The CVE report doesn't mention remote command execution or whatever you could do with it. This is just improper input validation. And it looks as if this is, you know, maybe not so significant, but as you saw it is, I could run commands on the running container. And to give you an example of like why I chose specifically to use a story here, a demonstration that uses image magic and Node.js to spawn commands because this is something that people do. This is something that people may do as like a job server or something else. And this is like a screenshot I got from YouTube of a video from Google IO 2017 event where they demonstrated a similar capability live to run the stage, doing the exact same thing, right? So this is a very common way to do things like converting images if you wanted to. But we need a way to help developers understand that. We need, why do developers think that that could be vulnerable? So like an application to image magic. So tooling like this makes it easy, right? It shows you this layer of, you know, layer level indication of where this is coming from. This is maybe me doing up to get installed image magic. And if it's coming from somewhere else like the base image, it will tell you it correlates the Docker file run and whatever directives you have to with the actual vulnerabilities themselves. So you know where to look for the problem itself. But even so, right? So how do you fix it? Like I told you there's like, you know 862 vulnerabilities in this Node 10 image. What do you do about it? I searched Docker Hub before and it has almost 4,000 different node image types. Which one should you move to? To 10.5, to 10.6, 10, to 12 something. You have no idea, right? And this is where we're trying to be helpful. So you have no idea if a new version is gonna be, you know having more vulnerabilities, less what's gonna happen there. This is where the tooling really helps you. This is where developer first security really shines because it gives you this database recommendation that tells you, hey, there are, this is the image that you're using 862 vulnerabilities but you can move into a different, you know kind of like base image. You could upgrade to maybe node 12 or you could just stay at node 10 but use an alternative. No image that's like a little bit smaller has less dependency footprint. Maybe that's just enough for you to run your applications. So, you know, we talked about code, right? You writing your own code like this kind of lines of code of what I had there. And we talked about using open source dependencies and the issues that they may have. And we talked about your container, right? And your dependencies, runtime as well. All of this that we've talked about but what did we miss out? We talked about all of those things but how do you deploy? How do you deploy an orchestrator applications, you know in production, in deployment time? That's the thing right there, right? We have commoditized infrastructure in the form of code. And I can hear, you know the thoughts in your brain running around, you know asking me for examples, what do I mean by that? So let me show you your infrastructure as code. Whether you're doing Kubernetes day to day whether you're using, you know, Docker whether you're, you know a Google compute fan using Firebase maybe you're a, you know front-end developer deploying to, you know to the cloud, you know, the front-end cloud if you've ever run any of these commands in the past then you have taken advantage of infrastructure as code and you are effectively now, hello you, yes you are a cloud native application developer and that means you need to basically concern yourselves with everything related to cloud native application security. And this is really the last piece of this puzzle, right? This is the bottom of the iceberg an entire application orchestrated using the power of code. And why are we even discussing, you know these kind of things, right? Because these are nowadays, you know the cloud infrastructure that has been completely obstructed a ways, you know from, you know anything the hardware based into into the form of code where we can deploy it as fast as we're deploying code we're deploying infrastructure. At the same time, those mistakes that we make in configuration are the number one cloud vulnerability as is identified by the NSA. So let me give you some examples for this. This is a Firebase configuration that adds a rule so that only authenticated users can view or create documents. You know, this is a good story that I have from like a real-life application. This is a really use case where this was a security misconfiguration because what's going on here there is no authorization implemented there is authentication but no authorization. So the fact that this is, you know there for you built, you know by default doesn't mean that it's with security by default enabling and protecting you and maybe you have disabled sorry, maybe you have enabled only specific users to log in but you forgot to disable registration. All of those are really ways for someone else that if you have done any cloud misconfigurations you're for them to basically exploit those concerns that you have missed. I'll take you to a Kubernetes examples where this is a partial Kubernetes demo file that will deploy a pod that the, you know the full, you know this is just part of it but the full one deploy is just fine. The only problem is it's missing out some crucial security related hardening that is not turned on by default. One of those issues with Kubernetes is this thing called the security context which if you are missing it then it allows you to run application without root user control and this pod level, you know directive now fixed it the fact that I added it but I've no idea like I'm not a Kubernetes engineer I'm just a developer so how do I know if I have more issues? I don't know about issues it's like who knows this stuff? So that's why we need again those developer first security platforms because they point out the issues in the form that we developers understand them and that they are showing us how to fix them and why are they even happening and where are they happening within this code because like everything has now been abstracted away into that form. So I would like to leave you off with several takeaways here, right? One of them is, you know connect your source code repositories to continuously scan them. I want you to connect your container image registries always so you can continuously scan them as well and have this, you know not have that drift like continuously monitor what you have deployed as well as what you have in your source code repositories. If you can, you know perform minimal base images secure base images however you're managing those but you know be able to act with some kind of image base image recommendation advice or if there's a vulnerability that comes into life you know where to move to very fast. And lastly, you know don't forget your infrastructure it's just as vulnerable and take measures to monitor it and fix it. So this is our session I want to, you know wish you a safe journey here in this like cloud idea of applications security space because you're all cloud idea of application developers and there are some resources here and we'll show them there's like a lot of security chitches and how to do things the right way in different contexts of technologies you can find them on this sneak.io.slash blog and with this I'll go ahead and let's go to the questions say some of them are already there. So I'll go ahead and go through some of them. Thank you for this questions. First one was how are dependencies marked? How often do you upgrade marked? Okay, so I'm going to assume this was based on the marked dependency here which you may have got that we have this plugin that shows you when you type something in it kind of like annotates this. This is if I got the question right like how do we annotate that? This is based on this one cost plugin and how often do you update to marked? So well, if there's and there's the context of being on the bleeding edge but also being very wary of being on the bleeding edge is important because sometimes you could just be a victim of malicious security incidents like we've had before with event stream and DSLink scopes and others. So you want to automate that process through things like the sneak tooling that helps you upgrade those. And we have inherently added this kind of like artificial delay where even if a version is out it will delay the upgrade a specific amount of time that we have observed from other recent incident security incidents that took time to find those issues. So that's how we automate it away. You could do that or you could like use something like a sneak see life you needed to like automate whole workflow based on your own processes and pipelines. That's this one, what else? How about container registry in enterprise cobalt to reduce the security vulnerabilities? So container registries not sure about cobalt specifically but if you have container registries what I'm suggesting here is if you, this is basically this takeaway which I don't know if this was there before but if you connect those container registries wherever you host them whatever cloud infrastructure into what you monitor like your application security monitoring thing then you can actually see those vulnerabilities in runtime runtime meaning here not the runtime of the container but like when we find new vulnerabilities that's when we will tell you of this stuff happening. So for example, I'm monitoring here this is from Docker Hub so you can see the source I've connected this I have this image here and anytime we're gonna scan this on a daily basis and anytime there is gonna be new vulnerabilities or maybe new recommendations to upgrade to different versions you can see for example if you move from node six which is super old end of life you can move into different node 14 which is long term support and this is a great way for us to basically win this win this, you know less vulnerabilities at XRFS so it tells us how to do this and this is kind of like the way to connect what we're having on the image registry and what we actually want to have running in production as well in a safe way. Great question. So if this and this is maybe the last one does this feature Infra as code Kubernetes template scanning works with Helm? Yes. So that was answered live. Thank you for that one. So we have support for that that's already out and you could probably take a look at the sneak blog and other resources on the sneak website to see both roadmap of what's coming next. Helm is supported and the Kubernetes channel file as well. More information is definitely they're being accurate on like the timing and releases and the exact feature completeness that we have there. But yes, this is let me take that screenshot back again and this is basically the Kubernetes that channel file that we are I'm showing here the screenshot. All right. So I think we are going to wrap up. Thank you for all the questions. Hope you enjoyed and I hope you're going to be stay safe using open source software. Great. Thank you so much to Laurent for his time today and thank you to all the participants who joined us. As a reminder, this recording will be on the Linux Foundation YouTube page later today. We hope you're able to join us for future webinars. Have a wonderful day.