 Let's start. What I'm going to talk to you about, and this is actually going to be a fun lecture, because we're going to talk quite a bit also about, we're going to do some actual hacking, which is always nice. So we're going to talk about first line of defense, how we can also patch using Cloud Foundry and the Cloud Foundry infrastructure, automate patching of critical open source vulnerabilities. We'll also do some hacking around them, just about me, two sentences. I'm a VP product at Sneak. At Sneak, we help developers and organizations use open sources to stay secure. We won't be touching too much on that, but that's the world that we're touching on. And I was, you can see here the roles of where I was. Quite a few of the people that are in Sneak today, I know from back in those cyber days. So we're going to talk a little bit about the open source usage, the growth there, how security relates to that, update versus patches. We're going to spend, hopefully, most of our time doing some hacking, then quick summary and Q&A for whatever may come up. So first of all, open source is awesome. Open source is eating the world. So it's why rewrite something that's already written, that's been tested, that works great, and not focus only on writing the exact core business logic that you need. And we see this as a key driver for digital transformation or however you want to call, fast moving teams that need to move fast and use whatever they can to do that. This is growth that we're seeing year over year. So we're seeing exponential growth in the number of packages that are being added each year. It varies between some of the ecosystems. You can see that in Java, it's more or less a little bit lower than 30%, so about 28%. In some other languages, by the way, such as JavaScript, we're even seeing a much larger growth. But still, a large expensive growth year over year. Any ideas how many open source Java packages out there in Maven Central? Guesses? 1, 10, 100. How much? 20,000. Another guess? No? OK. So 229,000 packages, libraries. And again, this is a 30% growth year over year. And you can see some nice numbers when it comes to the other languages as well. So a very large number. Downloads per ecosystems per year grow between 15% and 100% year over year. So both growth in the amount of open source packages out there that developers are using for various needs, but also in the actual usage. And we're also seeing a similar thing with Docker. So more and more of the very high growth in the number of publicly available Docker images. So most of your application code is open source. Usually over 90% of the code that's actually being developed, executed, and deployed eventually is open source. Just to look at our small spring boot app that I prepared for today's demo. So this is one of the three files that I've created. It has overall 80 lines of code. So that's an impressive app that you'll see us hacking later on. And these are the dependencies. So as you can see, there are seven direct dependencies. One of the things that happens with open sources is that each open source package, in turn, uses additional open source packages. And then there's actually quite a lot of open source packages that you're bringing in. Again, running in production, deploy parts of your app, you even necessarily know and aware of that. And you guess for how many dependencies overall, this miraculous app is actually using? 500 is a good number. It's actually over. 500 would have been more if it was in the NPM or something. But this is 66 total dependencies. So still a large difference. And any idea how many lines of code overall? Quick guess, 100,000? A couple of thousands. So 713,000 lines of code. And that's with the sprang, which is even more lightweight. So by the way, I am counting in the 713,000 also the 80. So that may skew the numbers a bit. But yeah. So anyways, the line share by far, and obviously this is a demo app. So it could get to 90 something percent and not to 99.99 like it is over here, but still the majority. Open source is cool, it's great, but it does carry risk with it. Here are some examples of known vulnerabilities that are disclosed and then were exploited and have a very large impact in the latest years. Heart bleed, a remote code execution vulnerability in OpenSSL, heard quite a few organizations and across a few of the OS's. Shell Bash, that was ShellShock. There was a Bash vulnerability. Also a remote code execution within hours of the disclosure. There were large-scale denial of service attacks, all coming from compromised computers that this vulnerability exploited. And there's then famous, which we will hack today, Apache Struts 2 vulnerability, which was used to hack into Equifax last year. Probably most of you have heard about that. And especially if you're scored in the US and exposed records of over 143 million, actually there were a few more millions that were discovered later. But anyways, so known vulnerability is an open source. As open source creates more and more components, as more and more people use it, and as the ROI for hackers to exploit known vulnerabilities is very, very high, because to exploit a known vulnerability is very easy. It's public. The code is open source. You can just write an exploit. It's in the wild within hours. And also the ROI is high because many organizations are potentially vulnerable that draws a lot of attention. Bottom line, a lot of attention is drawn. And we can see a large increase. This is in the open source application dependencies. So very large increase. Any guess on the trend when you're looking at the operating system of vulnerabilities? For example, if we take RedAtLinux, thoughts? Thoughts and prayers. So actually there we're seeing an improving trend. So the main explanation for that is that it's way more mature. There's not huge amount of growth in the number of libraries at the OS level. They're managed by, obviously out of the 200,000 packages you saw before, they're managed by various maintainers with various level of security knowledge and experience and tactics. So there is some hope that we will, with time, maturity, and putting things in place, we will get to that level of maturity as well also in the application world. And but still over three quarters of the top 1,000 containers out there have known vulnerabilities in them. So most chances you download a Nubuntu container or RedAt1, it's vulnerable. So what happens in the operating system world? So in the operating system world, you have companies like RedAt and Canonical that have your back. So here's an example of a vulnerability in PHP that was discovered in all versions of PHP and enables it to run arbitrary code. 5.3, the version 5.3 of PHP has retired. So they didn't issue a fix. So there was no fix on 5.3, only 5.4. But if they would have upgraded one of the RedAt Linux distributions that had 5.3 on it to 5.4, obviously there could have been quite a few backward compatibility issues that eventually developers or sysadmins would have to resolve. So came RedAt and they back ported a patch, a fix for 5.3. And so that means that if you're trying to look at how can vulnerabilities be fixed in the operating system world, it's easy. It's easy. All you need to do is run yum update, open SSL, apt-get update. If you're in Ubuntu, if you're in Red Hat, you restart the machine, and you're done. You don't need to take into condescerators and to test or to think about whether this will actually break your entire machine. In the application world, it's not exactly the same. So Struts released 2.332, which had the fix. But many organizations had a 2.3 that was four or five years old. Now try to upgrade four or five years old of Struts with all the versions. You restart that, it would just not work. So there's a lot of resolving that needs to happen. So not that easy in application dependencies. So why not upgrade now? Like every vulnerability we're seeing, why not upgrade it, as we said before? So one of the reasons it might break functionality, right? Like we said, you upgrade four years of Struts, you rerun it, maybe there's a good chance is that functionality won't work there. It could be that there's no fixed version, so you just can't upgrade. Or that you don't have a direct dependency upgrade. So think about a situation where I'm using A that uses Struts, and A just doesn't have a version yet where the updated Struts. Now you need to, so there's nothing you can do. And there may be version conflicts in others. So what we're suggesting, and we'll take a look at that, is how to patch first. So just patch quickly for whatever reason, free the developers from needing to address something that's very hard now, like upgrading four years of Struts. First of all, you need to find the patch, where's the patch. It may be fixed in a newer version, like happened in Struts. There's some that are less maintained, some packages that are less maintained. And then an external PR, a sort of pull request could be there, or you can always write it yourself. And then you need to apply the patch. So you found the patch, how do you apply it? You can either fork and apply it by yourself. You can do a static build time patch, or you can dynamically patch at boot time. What we will show in the Struts is the approach where we take the fix from Struts, and we build it in patch time. And now comes the fun part of the demonstration, which is actual hacking. So let's take a look now. What I have here, OK. First of all, I have here two running apps, Spring Goof. And to do exploit, to do exploit is, you'll see soon, is a Struts app. And Spring Goof is a Spring Boot app. To do exploit, this app is the amazing to-do list app. So I can, in a second, I need to log into this amazing app. Or does it not let me do that in a second? I just want to show you this amazing app that we prepared. It's called my to-do list. You can see that I can create a to-do, right? Can do a hack. You can do it 1970. As you can see, this is a very impressive app. And I added here a to-do list. So this is that Java to-do list app. And now what we're going to look at is that if we're looking for a second at the, this is the infamous dependency tree for that app. So as you can see, we're using this web comment. And as you can see, obviously, like we discussed before, every dependency has a lot of dependencies that it uses. And this one is used, and then this one is used, et cetera. And somewhere here, we're also using, and these are all ones that are marked as vulnerable. But what I want to show you is that we're also using here the struts to core component dependency, which has this arbitrary code execution vulnerability that we discussed, version 232, it was fixed. And that vulnerability, what it does, it enables you to run code in the content type. So what they actually do, and we can see the code here, this is the actual patch that fixed the struts vulnerability, which we then backport in order to patch. And I'll show you that in a bit. You can see here that on this localized util, at this fine text function, the message, it executes here e.getMessage. This actually tests the code. And if there's an OGNL, the Object Graph Navigation Library, a code in it, it would actually execute it. Now, this is the fix where it doesn't if everything's OK, and if not, it disallows it. So let's now actually go and hack it. So one second. Can you see well enough or not, really? Zoom in here. This better? OK, cool. So let me see one second where I am here. This is the Java. This is the one we discussed. This is the to-do list web struts, the app we just saw that has this exploit. If I go, I have here this exploits folder. Take a look at this file. And you remember, this is the actual malicious piece. So in the content type, this ampersand here, this is exactly what runs this OGNL that we saw before. And here, you can see that somewhere, we define here a process, which we start, et cetera. We run bash. And I have this command, which I'm going to just replace with any command I want to run. So this will eventually execute any code I want in a new process as part of bash file. Cool. So what I'm going to do now is I'm going to show you how I'm actually exploiting it. So this would be running the nth command, and then it would be running the etc password command. This is a live demo. So if something doesn't work, don't kill me. Yep, so what happened now? I ran it. And you can see the HTTP request. You can see that this is the content type that came as part of the HTTP request. And you can see here my env. You can see here all my environment variables as they are. I'll show you another one as I promised. We can run here etc pass word and pass wd. This is my etc pass wd. And any other command you want to execute locally. Cool. So we have this vulnerable situation. As you saw before, we have this application with all its dependencies. But upgrading is hard. For all the reasons we said before, we don't want to now upgrade four years of struts with all the application implication that it will take us. And we don't want to stop right now and freeze all our R&D to do just this. So we're saying let's patch first. So what I'm going to do, and this is how I'm going to actually use Cloud Foundry to do that and to automate that, what we have created with Cloud Foundry is we've created a build pack that instead of the regular Java build pack, and now we've implemented it into the Java build pack, what it does, it's here, that build pack would also patch any critical vulnerability that we had configured for it to patch. So what this would do is it would create a push to do exploit the same vulnerability we had, the same war file we had. So nothing changes. But just the build pack in build time has a configuration that if it finds this such a high vulnerability in struts 2, it would patch it. Again, taking that same code, the same patch, we backported it to previous versions of a patchy and of struts and would patch it. So this would run now. So what I wanted to show you after this deploys is how now that same app is not vulnerable anymore. Meanwhile, just as this takes place and not to keep you bored, let's do another hack. So what we're going to do now is we're going to look at a second application. This one has the spring break. So this is my application, simple rest app. It has, let me show you, it has very simple. I can look at items. So sausages, milk, beans. I can look at the first item. I can find items. I can very simple app. This is with Spring Boot, and it's a rest application. Now, spring break vulnerability. Who here heard of spring break vulnerability? Very big vulnerability found in Spring, enables, again, remote code execution, found just very recently. We can look at its definition. It was found in REST Web MVC. And again, it runs a similar expression language that's similar to the OGNL, which we saw just now at struts one that enables you to run malicious code when you're using a patch request, which is apparently an HTTP potential parameter. So now let's go to exploits here. And I'm going to show, again, how this one can be exploited. Let's look at this text. So what it would do, again, it would do this replace op. And this code actually is the one that's running, would run and execute your code, everything that's here in command. Now, let's run, let's see, the exploits I have here. And I'm going to run actually this one. So what we're going to do is run this text. We're going to change the command with env. Again, let's run env. And look, it's a regular easy curl command to this REST API. Just puts the patch parameter, and that's it. And again, puts the text here as the content type. And once I run this with this item, I get the env of my computer. So another example of a critical vulnerability. Look how simple it was to exploit it. This was one in spring, actually. So we're done here. We just had a new vulnerability come up, a new version came out of to do exploit just now, three minutes ago, deployed. I'm going to try to see if the patch actually fixed something. So this was trying to run, again, as you remember, the env against the to do vulnerability. And I'm probably not in the right place. One second, Java goof and exploits. OK, let's run it again. This time, I'm getting an exception. So this time, I'm getting an exception of invalid input. And that's it. And I can't see the env. So vulnerability patched by build pack, automatically by Cloud Foundry. Thank you. So I want to summarize, again, kind of the approach and what to do. And so, again, first line of defense, automating patch and app dependencies. Patching is actually an old concept in the operating system. We saw that before with what Red Hat and Ubuntu are doing. Very easy. They create a patch for you. All you need to do is run a yum or app get, and you're done. But a very new concept in the app world. Application dependencies, if you really think about it, are just pieces of OS, of infrastructure, that are within your apps. Why not treat them the same way you treat operating system? So prediction. Automating build time patching, which we call in coin and Gartner is also a coin for us precision patching, will become the easiest and safest way to resolve vulnerabilities before attackers exploit them. So again, key vulnerability, not easy to upgrade, release today. You'd want automatically Cloud Foundry in the build pack to patch them today. So even if you just upgrade two or three weeks from now, you're still covered. And Cloud Foundry and Sneak, as the one sourcing these patches and helping you out, make it all easy. Yep, so bottom line open source. We discussed important define, fix, prevent, and respond to vulnerabilities. Open source is awesome, but enjoy it responsibly. That's it. Any questions? I think I tried to run, so I have one minute for questions or maybe two. That's a great question. So we also have a on-prem registry of patches that we can maintain. And that's the way it could happen also on on-prem. I must say we're also looking, it's not as common yet, as well adopted yet, but multipacks is also something we're looking to use this and just add patching as another build pack as part of the multipack. But yeah, today we have it as either a store on AWS open with all the patches, or we can provide it kind of an online registry for it. Privacy settings, select locations. I don't know why that happened. Yeah, sorry. APIs. Yeah, yeah, definitely. We have on-prem solutions that are coming. We have quite a few banks and such that are customers today that would want this to run only on-premise, so whether it's on their environment. So yeah, definitely. So do you have it as an offering? No, we have it. We have it as an offering. Yeah, we have already quite a few customers that are using it. I'm getting the t-sign, but maybe someone has one more question. One more question. OK, it's been a pleasure. Thank you very much, everyone.