Security should be one of the first things that comes into mind when you create Java software, Java applications. I would say security first, but I will get into that later. I'm going to break into Java application, but first we need to talk about this word, devsecops. We all probably know Devsecops, right? A lot of people try to practice DevOps. And if you are not aware, if you do that, think about the following thing. Are you creating software? Are you responsible for putting that into production? And when things go wrong they will call you to fix it. If that is what you do in some way you are doing DevOps, you are taking responsibility for the software that you create. There are a lot of practices around DevOps, but the major thing is that we focus on developers and operations. We tear down walls between them and make sure that they work together and we own our stuff as a team, both during creation and in production. There's one thing that's not particularly there in many cases, and that is security. That's why I say security first and it's right there in the middle. However, when I saw this word the first time I thought it was a buzzword and I'm like, yep, what's next? Dev, cloud sec? Biz, devsecops? The point is, in my opinion, security should be part of the development lifecycle, just like scalability and maintainability. And it should be part of the upcycle because, well, maintainability and scalability is also something, for instance, we do on the upside. So security should be an integral part of the whole dev DevOps thing. But it is not. That's why the word devsecops is emphasizing on that security part, because we need to think security first and have it as a primary mindset next to things like scalability, maintainability, readability and all these abilities that we are creating for our code. So let's focus on that security part and what we can do as developers. But first, my name is Brian Vermeer, I am a developer advocate for sneak. I am a Java developer by heart and I do talks. I recently became a Java champion, so I'm very grateful for that, that the community chose me to be one of the few Java champions in the world. I do some stuff for the community like the virtual jug and the national Netherlands jug, the NL jug and a bunch of other stuff. I really enjoyed it, giving talks and sharing knowledge and most of the time sharing things about being a secure Java developer. But with that devsecops thing, we're trying to solve a problem and I already shine a little light on it to see what that problem is. But let's split that out because, for instance, ten years ago, so it's almost a decade ago, I worked for a bank, and before that I worked for a government agency. And what happened there is that we created software, but the time from creation to going to production was. There was a long time between that, actually, we went to production three times a year, and that is not what you want today. I mean, we try to speed up things. If you look at ecommerce or basically all applications that run productions, it can be sped up to things like three times a day instead of three times a year. Point is that we focus on new features, right? That product manager is looking that, let's get that feature out as soon as possible to be before our competitors, to win that battle, and that's a fair game. However, in many cases, we cut corners and security is at that point a little of the things that we're like, yeah, fair enough. So there is a lack of security focus throughout the whole application lifecycle. And that's because although we try to tear down walls between developers and operations, security is in very much almost all companies. It's still a siloed thing. It is not something that is adopted by the development teams or by the DevOps teams. It is a team that works separately, checks your stuff and say you work in a three week sprint or cycle, and after three weeks you created that feature and you're ready to go to production. And then somebody comes up to you and said, yeah, we tested it, but no, that's friction. I don't like that. I worked my butt off to make sure that this feature works, and then somebody comes up to me and says, I cannot put it into production because others might be a possible security issue. Wouldn't it be nice to have these things and that information already available to you? Just like you want to have quick feedback on your unit test, because in the end, we need to think of the same things altogether. In the end, we do not want that customer data that is in our application is compromised and we are the next headline in the news. We want to prevent that. So how bad is that situation? Well, who of you have heard of a company called Equifax? And I know it's an example from 2017 already, but Equifax, and you see some headlines over here. Equifax is a commonly base in Atlanta doing crediting scores, but the company's not important. They built their business logic on top of Apache struts. Apache struts two. In that case, that particular version of Apache struts was vulnerable. And their business logic, I assume it was okay. But because the plumbing, the foundation, there was a vulnerabilities in that people could get in. Because a vulnerabilities was found, people could get in and nobody in the company noticed. Basically they were not aware that this was happening. So people could snoop around in that system for months. I don't know how long they were in there, but they were in their head, they took their time. In the end, over 140,000,000 us customers were compromised because the data they found they brought out into the open. And that's not what we want. But let's look into that hack right away. If we go to, let's go to this one. And you see this is a Java application and it runs on Heroku, it runs actually on the cloud. I can sign up, that's okay, let me sign up, that was Alexa. However, let's go into this application. I don't actually need to sign up because it's in the plumbing. So let's go to this thing. For instance, I can do a curl request to this application outside of the actual Business logic and do some weird, weird things. Let me enlarge this for you a bit. So I have a header over here, and this header is what I'm going to use. As you can see, this header contains a content type and that content type. This is the value of that content type. If you look closely, you probably figure out what's happening. And if you know what kind of content type this is, well, we can at least say it's a faulty content type. It's a content type that is not really there. It is not something that is valid. And the point is, when you use a content type like this, with that Apache struts version that we are using, it's the same Apache struts version that Equifax used at the time. We go into an exceptional flow, and in that exceptional flow it is possible to utilize OGNl, the object graph navigational language, basically the expression language within Apache struts. And with that expression language I am able to interfere with the objects. I can call getters, setters, that kind of stuff, but I also can create new objects. And what I'm doing here is I am creating a new process builder, right? And that process builder, I feed it the bash, and that bash on its turn is fed an arbitrary command. So basically what I'm trying to do, I'm trying to spin up a new process and feed it a Linux command. It depends on what privileges this application is running, for instance in a docker container or whatever, it doesn't matter. But the point is I can feed it basically any arbitrary command. Let me show you, I have some applications over here and let me go to into the exploits. I prepared something, so let's go and look at the n variables. So what I'm going to do here is I am going to call the command nf. I substitute, I use this header I showed you, I substitute command for the command nf, which basically is a Linux command that shows me all the environment variables. I am doing a curl minus v on this thing, but this is a localhost and our application runs on Heroku, right? So let's just do it. This is the application, let's just go over here, let's use this one. So instead of the localhost I am inserting my cloud application and let's see what happens. And what happens is you see a lot of stuff over here, but you see that I'm HTTP 200 and in my result I now have part of the environment variables on this local machine. So that means that this function, this command actually executed. And now I see what the environment variables are. On this particular heroku instance I can see the Java ops, I can see where Java home is. Let's keep this one in mind because I need that later for another hack. Point is if I can call the NF command I probably am able to call other common as well. I might be able to create a script to download software, call that script. I basically have a lot of power now and I can do whatever I want depending on the privileges. I can execute arbitrary code and that is not something that we want. And just because I'm using a outdated version of Apache struts and I didn't update it when there was a newer version out, that is basically what happened to the folks from equifax. So continuing on this, let me get my application back like that. Thank you. Let's go into your application, say this is your application, this is your Java jar or Java war or whatever it might be that you want to put into production. How much of the code that you put into production is actually the code you have written? Because you probably use the spring initializer or any other initializer that generates a part of stuff. Plus you might have a pum or a gradle file that imports a lot of stuff from framework libraries. You get me right? And the answer is this is probably your code. This is probably the code you wrote and Danny's there at hole. That whole big yellow ball is dependencies, and dependencies bring in, dependencies bring other dependencies in. There's a lot of code that you pull in from the Internet and use for good reason. Because we do not want to create yet another corrupt repository or yet another rest endpoint. We want to focus on the business logics. That makes a difference. However, we take a lot of pride in that small red or purple bowl in the middle. We do code reviews, maybe we have a QA system in place. We try to make our code neath, speedy, maintainable, and we do code reviews and that kind of stuff, pair programming. But how do you maintain your dependencies? In a lot of companies, once a dependency is in, it never gets out. And do you update them? Are you aware what's actually working there? What's happening there? Let me give you some numbers. Examples. Say this is a node application, because it's easy to make fun of JavaScript, I'm sorry. Say this is a 19 line serverless code application, JavaScript application, and I'm using two dependencies, AWS SDK and node fetch. So two direct dependencies. But dependencies have dependencies having dependencies. In the end, we will have 19 dependencies. Not so much in my opinion. That's okay, but how many lines of code do I put into production? Drumroll. It's just a little bit shy of 200,000 lines of code. And then every node developer comes up and say, but not every part of that code is available or is actually, you can execute it. True, but do you know what can be executed or not? But let's move into a Java example. I have a spring serverless example over here, and this is just a code snippet because the code was 222 lines of code, and that was an accident that it was two, two, two. However, it had five direct dependencies. And these dependencies, like from the spring cloud framework and AWS, again, it came back to 54 dependencies in total. Now the question is, how many lines of code do I actually put into production from this neat two on the 22 lines of code, spring application, guess what, over 400,000 lines of code. Almost 500,000. And I'm responsible not for the 222 lines, no, I'm responsible for the whole shebang. So all the 400 something lines. And remember, how does Java work? Every jar that is included in my application or that is there, is available. Well, most of the time is available on your class path. So it can be loaded into memory and can be used, for instance, with a arbitrary code insertion like I just showed you. So we need to take care of both these parts, not only our code, but also of somebody else that we pull in. And we know that open source usage has exploded in the last couple of years, well, the last decade, basically. The problem is, I won't say open source is not secure, but open source isn't secure nor insecure, if you know what I mean. I mean that open source is created by developers just like you and me, and you might be an open source contributor. And as we know from our professional lives, maybe we make mistakes and mistakes will be found over time. So we need to be aware of this as well when we use open source available software. Get me? So think about the next method. If you use a package that is well known, well used, and well used by a lot of companies, that means if there is a tiny flaw in it, or a big flaw in it that attacker can use, he has a potential reach of targets that can go into millions. For instance, if there is a problem with spring boot or take any big package, and there is an issue with that, a lot of people are using that. So one vulnerability can get into many victims. And most of the times these vulnerabilities are already fixed, you just have to update the version, a few numbers just for the sake of it. Total packages indexed per ecosystem. And this is already a little bit of old an graph, but this gets the point. Between 2018 and 2019, NPM grew tremendously. So that's JavaScript. During 2019, they were over a million packages. However, if you look at Java, which is the blue purplish line, Maven Central, in this case, the increase of the amount of packages is over 100,000. So there are a lot of packages coming there every year, and that's because of new updates, et cetera. But if you look at new vulnerabilities that are found each years, this is also rising because we find vulnerabilities over time and packages are using packages are using packages. It can be that it's not just the package that you import, but something underneath. That's what we actually found out. Over here, right in the middle is maven central, and you see that most of the vulnerabilities that are found are indirect. So in the layers below the package that you include, and that's fair. So think about that. Pulling in a package, what do you actually take with it? We ask OS maintainers, open source maintainers, how confident they are about their own security knowledge. And 63% says I'm kind of confident, and that is just as confident as you and me. But we have base programming and we take a lot of pride in our own code. However, we pull something in from somebody else that we trust blindly. But who is responsible for security? A lot of people say it's a shared responsibility between the security teams and operations. But most of the people think and believe that the developer has a fair share. Developers need to take responsibility for that. And I think it's logical, because we build this stuff, we know how we built the stuff up, we know what kind of technologies we used. And people trust our software, our clients trust our software, just like I trust the person that built this house I'm currently standing in. If he is not aware of regulations and the security that this building will not collapse, I wouldn't be standing here. Very comfortable. Same holds for software. Well, we can go on and on. Like how do you find out about vulnerabilities? But 27% said I probably won't. This interesting one, who of you works with legacy software? I think a bunch of you. And it takes some time for a vulnerabilities to get discovered. The median over here in this case is two and a half years. So over time things will get found. And if it's in production for a long time, you didn't dare to touch it because, well, nobody owns that code anymore. That happened for a bank I worked for a couple of years ago. And if it's outward facing, you might be vulnerable. Docker also an interesting part. Who uses Docker? I bet a lot of you. I did a research in end of 2019 that pulled the ten most popular docker images from Docker Hub and we scanned them for vulnerabilities. And there are a lot of vulnerabilities in that, all these latest versions of these packages, because what you do is from some base image and you build your stuff upon that. However, with our scanning tool within sneak, I scanned our stuff and what we found out is that most of these things are built on top of a very large operating system, for instance, Debian. And then you have to think, if I want to pull in the node image, the node latest image, do I actually need the full Debian distribution? And that comes with a lot of binaries that might have issues as well. But we're not going into darker today. We asked people if they find operating system vulnerabilities and half of the people interview didn't. However, I want to go to the hacking part because that is interesting. And I want to start with a very small code application to show you some basic vulnerabilities. And I chose a node application because, well, we found this vulnerability. However, it is not so much because it's code, but it is because this application is vulnerable. This is an application in node JS and it is a to do application. And what I can do, I can pull in things like buy flowers and I can make a list of that, nothing really special, what it can do, as well as at the bottom over here you see a link, a static link to an about page. And you see that this is the best about page ever and the best scalable page ever, because hey, you can scale it. So it works on mobile and the contrast is good and everything is great. However, it's not the point. The point is that this is a static HTML page and it served to you by a library, a node JS library called St. We use the version that is vulnerable. And let me show you what the vulnerability is. It is a path traversal vulnerability. So going into this app, let me use curl and I think that is the best way to do so. If I curl this and curl the about page, I need to be on the right screen. Yes, say I curl the about page, then I will get the HTML perfectly fine. But the point is there is a path traversal vulnerability in here. So normally a path reversal would be something like this. What we try to do, we try to go back into the path. So out of the public folder and basically I'm trying to get out of the main folder where the web server is located and go into the root of the current system, of the actual machine. However, by doing this I get rerouted back to my home page. You see here is the link to the about page, et cetera, because the St libraries is a real library and it basically denied, specifically denied. It recognized the dot dot slash and it says okay, you're doing a path of Russell. No way. However, that's exactly what I'm trying to say. It try to it specifically deny to dot dot slash. So if we are a little bit smarter we can go and do something like maybe escaping or maybe encoding. So what is the HTML encoding for a dot? Let me just tell you that is percent to e. And if I'm using percent to e, which is the encoding for a dot, I just do dot dot slash over here. And if I do dot dot slash over here and I just let me just do it right, let me copy the whole thing like this. And now I'm in the root of my current local system because I'm using the wrong library. But if I can do this, I can also go into a file like the passwd file. For those who don't know, if you dot dot slash you will get back into your path. But if you are in the root and you dot slash in the root, you will end up in the root. So it doesn't matter how many dot dot slashes I do at this point. Over here I'm in the root and I'm going to the etc folder and going to the passwd file, and as you can see, it can be shown, and this is on my local machine, but I can also put it in the cloud somewhere and it works fine. People say yeah, okay, but you can only read now. How important is that? How important is it when you can only read this stuff? Well, it is the start of a journey, because now I can read into files that are there, and if your web application is not really well configured, I might be able to go into a certain place that you don't want me to be. I can snoop into the files, may find tokens or credentials to a database, et cetera, et cetera, et cetera. For instance, what I can do is if I'm over here and instead of going to the root, I can do the percent to e over here, and I'm just going back one directory in the path breaking out of the public directory, which shouldn't be available, but I can't. What I can see over here is that I can go to the package JSon, which is basically the NPM way of specifying your dependencies, just like your palm XML or your build Gretel. And if I do this, I can see what kind of dependencies you have. Like it uses DMS library, I know that one is vulnerable, et cetera, et cetera. It uses the express library that is vulnerable this version. And I can look that up because that information is available on the Internet, right? Even more path traversal and looking into files I can look, and this is Javascript, and that's why I don't like it. I can literally go into the JS files like the app JS, and somebody forgot to get their token out. It is interesting if the stuff is open sourced, fair enough, it would be already on GitHub. But if it's not, I can see what the actual version is on the server. That might be interesting, right? And with this token I can go on and on and on. So it is a start of a journey, right? Okay, let me move to Java example. And this is interesting because I'm going back to that previous example of the application I showed you, and you see this to do application. Let me sign up this time. So I'm actually going into the application. No, let me just sign in with my email address like this and put a password in like 123456. Because hey, I work for a security company and this is safe, but it's a demo application and it will be restarted in 15 minutes after this talk. So I sign up, I'm in this application, and again, it is a to do list. What I can do over here is I can create a to do and I can create something fancy like eat pie with a PI symbol. I love that. I love this geeky stuff. So put it somewhere in 1970, and if it's already on the list because of 1970, I will give it the high priority. Great. And what you see over here is that I have a table that it is a to do and okay, cool. But the title is eat PI. And that PI symbol is transformed into an aSCII representation, the slash u whatever. So what it uses over here, it takes the title and goes into the native to ASCII function that is part of your jdk that is there. If you download a JDK from what vendor whatsoever, there is a native to ASCII function available and that transforms that symbol into the ASCII representation. Keep that thought. Hold that thought. This application can do something more. We can upload files, which is interesting, and it can upload zip files. But what if my zip file looked like this? So remember the java home I showed you earlier? Okay, now it will all come together. So let's look at the zip file I created over here. So I would call zip info on zip slip zip. And you see this zip file contains two files, a good text, which is a normal text file, which is there, and it contains a file with the file name. And we already found out that is a path traversal. And then that slash app jdk that I found out from my end variable that I did with my previous hack. And what I'm doing now is I'm trying to overwrite the native to ASCII file by extracting this zip file. So I'm going back into the root, going to the app jdk, basically the jdk on my heroku instance into the bin file. There is that native to AsCII file, and I'm overriding it, I'm trying to override it. So let's see if this works. And this is can actual zip file. This is a valid zip file. So let's see if that works. Let's go into that application again, choose the file and I need to go to my break demo files. It's over here. My zip slip. Let's say this is the zip file I just showed you and let me upload it. And what we see in the public folder where normally all the stuff goes, the good text is there, so we know that it actually extracted the zip file. Interesting. So what did it do with the dot dot slash dot dot slash thing? Did it silently swallow the exception and didn't show me which could be possible? Or did it actually execute it? Let me show you if I'm going to create another to do and I say hello folks and it doesn't matter if I put it, put it on the 2 February 1970 and give it a medium priority. But what you see now is that the title is now replaced with muhaha Gotcha. That is because I overwrote the native to ASCII file with a very simple file that echoes this string. So every title goes into that native to ASCII file and will be transformed in literally muhaha gotcha. And that is because I'm using a zip library to unzip my zip file, because others is no such thing in the java library, or there is no such unzip file in quora Java libraries. So we use an external library. It can either be from any vendors, there are a lot of vendors that do that. But this version of this library, and this was found by our research team, was there in a lot of libraries. Point here is that it looks into the zip file and it didn't sanitize the input. So the dot dot slash wasn't stripped away, it was just look into the zip file, create a file at the same place, overwrite it and put the same bytes in. So it basically took the path and the file name and executed it instead of looking hey, is this location actually inside the application where I want it to be? So not looking at the specific path, but you should be looking at the canonical path. Nevertheless it didn't sanitize that input. So what you see over here, I can overwrite files that are there on my system and have a different meaning, which is in first instance is a path throughsal problem, but that means I can insert arbitrary code. Interesting, right? Let's go from there. This is happening because I'm just using a library and it was already updated to a newer version because the vulnerabilities was found and disclosed. But I didn't know, I didn't look at it, it was already in production. Let's go back to that. First thing, you know that application I showed you, or actually this application where I showed you the arbitrary code execution with the expression language. A lot of people come back to me and say then, yeah, but that's Apache struts. Who uses that nowadays? Well, that might be the case, but let's look at another problem. Let's look at, is this the right one? Yes, this is the right one. This is a spring application, a spring boot application, and this is spring, we call it spring goof. Let me just enlarge this bit a little bit for you. I think if I can do this. Yes, cool. So this is a spring boot application and it contains a grocery list like beans for $0.50, milk for $1.09, et cetera, et cetera. Interesting, right? The domain is not very interesting as well. It is just a simple pojo that is serializable in this case, but contains a name and a cost and an id that is automatically generated and a lot of getters and setters in a two string. Nothing really important. The important thing is in the repository. And we probably are familiar with spring boot applications and the marvelous things that our friends from spring created for us. For instance, if I'm using spring data, I can extend the crud repository. And by extending the crud repository I do not have to create all crud functionality myself just by naming conventions like find all and find by name and giving it the right parameter. Like here it connects to the database that is available to me because of probably the dependencies I pulled in and it automatically configured it for me. I do not have to create the SQL string myself for the find by name. That is interesting. So I can really prototype very fast. Then I'm using spring data rest from a somewhat old version of spring. And at spring data rest I can use this annotation repository rest resource and that transforms my crud repository into a rest repository and gives me a bunch of endpoints. So basically my crud functionality are now available through JSON endpoints. Interesting, because if I can do this, I have a proof of concept and I can work on for instance my front end which might be a mobile app or whatever. But let's look at this application and that spring data rest because there's an issue with that. I am trying to run this application and I always have to pray to the demo gods that this application works. And as you can see it spins up and it has these items in. Okay, cool. So let's go back to a web browser like we see over here. And let's go to localhost 80 80. And this is the hell browser. My hell browser just is there to show you what I can do with different arrest endpoints. See the hell browser for spring data rest. So what I can do is I can show you items one, and that will exactly show me the first item on my grocery list, beans for $0.50. Cool. I can give you number two, number three. But I can also do something like hey, search find by name. And name is better. This is exactly the corrupt repository I have that is transformed into a rest repository. And by query parameters I can say hey, give me beer. And indeed it gives me better for 599. Cool, it works. And I probably wrote a bunch of tests around it, ship it, because now we can go into the front end and then we are done within two days. But wait a minute, I said there was a problem with spring data rest. Let me show you that issue again. I will do this from my browser or from my terminal, and normally I will put my hoodie on, but not this time. So let me show you this JSON file. If I do a curl request, in this case a curl patch request, give it a body, a certain JSON body, I am allowed to give it a body like this. And this is just JSon mean, it's a JSOn list with key value pairs only. What I'm trying to do here with this version, with this specific version I was allowed to, if I do a curl patch request, I'm allowed to execute SPL, the spring expression language. And I do in somewhat the same way I can create, in this case I call a runtime, like here I'm getting the runtime and I execute a command, get it as an input stream, reroute to an output stream to show you it here on screen. For instance, what I can do is let's do the passwd file again. So I say spring rest, aspoid passwd. Let me copy paste this for you so it's a little bit more visible. So I'm enlarging it a bit more. So what you can see over here and let me show you the second line here. Yes, over here. So I do a curl patch request and I'm using this body and instead of the common which was there in the first example, I'm going to the etc. And then patchwd. I call this patch, curl patch request on my item one, which was the endpoint that was created for me to show me my first item in my grocery list. So it's there for a reason and I didn't configure anything yet. This is just it. But if I do this, you will see that I have the past WD file or I see the input of my past WD file. Yes, in the end it will give you a problem with an SPL evaluation exception. But that's not an issue because the actual command was already executed. And if I can read a certain file, I can also create a certain file or delete a certain file. And again, same issues as we have with the Apache struts sync. So it's something that is happening in other frameworks as well. It's not just Apache struts and these things are happening in other framework and you should be aware of that, these things happening because it is not your code, it is the code that you imported. And that is now a problem to you. And you probably weren't aware of this, were you? So what can we do about this? Let's go into how do we and at sneak see a solution. So we have hacked the stuff, but the solution is three ways, culture, process and tooling. And they are equally important. First of all, the culture, let's go in that. And I say team culture, but it can be company culture or department culture. Let's keep it to culture. Because within the teams that we work with, we have a lot of different people. We have developers, security people, operations people, management and a lot of more. But we all have a different mindset. We all think about different things, we all find different things important. Developers want to create things, security people want to make sure that it's not breached. So if a developer doesn't create something, it's all cool. Operations people, they care about, hey, what you developed and what we need to go in production, how can I scale it up? Can I just put in more pods? Can I easily restart things, things like that, that are on the operational side from a traditional point of view. And management, they probably think about getting things done, making revenue, making sure that that feature is out. So we all have different things we care about. Different KPIs, to say it in a fancy business word. However, if we think about each other's KPIs and each other's point of views a little bit more, then we are up for a good start. If a developer takes into account that you don't want to get breached, instead of just making sure it works, makes also sure that you don't get breached by having good practices in place, that's already a start. So the security folks will probably help you out with that. So play along. Just like children, we need to play along. And for instance management as well. If they just pushing you to get more features out at a certain pace, is that fair enough? Don't you need to take care of things like technical debt? Don't you need to review what kind of dependencies you take in? You need to take time to clean up your house, you need to take time to maintain normally if you look at physical things, we need to maintain cars and buildings, we also need to maintain software. So from managed point of view you should take that time. We should be aware of that, that it's not only building on top of something else. So if we play along together, then we're off with a good start. If that's not the case, then I'm afraid it's kind of useless. Just bringing in more process does not work. Saying like hey, we are breached. And now you have this Excel cheat sheet or this Excel sheet sheet. You need to mark every test manually that you have done that, and that might work for a week or two weeks, or creating more processes in that you need to get actively involved in. That might work for sometimes, but in the end you will gradually get back to the way you were working. So why not do it the other way around? See how you create your software. What is the process for you for creating something? And make sure that you fit security practices in that process that you already have so it will not slow you down. One of these things are, well, obviously is automation. Why not scan your stuff? Why not create tests that are security focused? If we do that and then we can run something and we see if it's there or not, instead of actively testing, hey, can I breach this? Yes or no? So automating stuff is a really important part over here because we want to focus on the stuff that we are good at creating software. And then we have tooling, you need to pick the tooling that is right for the way that you work. So instead of hey, management picked a tool and we need to satisfy this QA thing that is there somewhere in my pipeline that's not a good way of working. We actually need to adopt the tooling that help us in the current process that we work with. And if we do that, we're in a good position, automate a lot and we at Snyk, that is our focus. We want to be developer first. So what we are doing is we can create scanning tools for you. We scan for instance, your dependencies to see if there are problems. And we can do that in every single step of your pipeline or better set your software development lifecycle. And what I will show you now is my tool that is a free tool. There are other tools as well, but the point is that you need to be doing this. So if I'm going to, for instance my intellij application over here, this is that spring goof thing, I can stop it and I have the sneak plugin available and I can run a scan and that scan will look at my, in this case my manifest file, which is my pump file, and see what kind of versions of dependencies are there. It abstracts the complete dependency tree and sees if others are issues or what that dependency tree is, sends it over to sneak and sees if there are issues. And there are a bunch of issues. And all these issues come with information. And what is the information and how should I remediate stuff like that? So that is from out of your browser. But also I'm more of a guy that loves to work from the terminal. So instead of let me see where I am, I'm in the exploits folder. So I'm going to the root of that same folder, the spring goof application, and I'm doing a sneak test. It's a common line application that can be done here as well. And what it does, it does exactly the same. Only now in my terminal, in the same way you might be able, and what you see over here, this is interesting, is that a bunch of these things can be fixed. And this is because I enlarged my system. But it says okay, issues with no direct upgrades or path. And in some cases there are here an improper input validation in some specific version of the spring web. But if we go up, yeah, for instance here, update spring boot arrest jpa one five five build snapshot. Yes I know, to two point twelve release to fix all these underlying issues. And of course if I just downsize my terminal it will have a better view. But I scaled it up to make it more visible for you at this point. But you see is by doing these kind of things on your local machine I have quick feedback. And that is interesting because when I have quick feedback, just like my unit tests, I can actually prevent that a library that I depend on will get into my repository. So by doing this either here or either in your ide is a possibility. But next to that we have things like that's on your left side, on the coding side. Then you have the repository in your repository. For instance, why not connect your repository to a scanning tool that scans on a daily basis. If there are new vulnerabilities found or new fixes found and actively ping you like hey, we found something in your repository and we have a fix for you. That's the important part. Not only pointing out that there is a problem, but also there is a fix as well. Why not for instance, scan every pull request that comes in for possible new vulnerabilities that come in. If not, you might break the build or you might be actively pinged. Depending on your process. In your CI pipeline you can do things as well. And now I'm only talking about your dependencies. But in your CI pipeline I can do that sneak test in the same way. For instance we connect with Jenkins and with GitHub actions and all kinds of pipelines. Or you can connect that Cli I showed you manually. Nevertheless, it doesn't matter what tool you use, but use a tool over there, but not just there. If you do it just there, that means that when you build there might be some time between coding and actually building in your pipeline. So that feedback cycle takes a long time. And before you go to production, you want to be safe at that point. And that is fair. That is actually fair. But when you build it from your CI pipeline and you want to deploy it after deployment, you're not done because we do devsecops. Why not make a snapshot in that point in time, for instance by using a sneak monitor, and that takes a snapshot of that point in time and scans it on a daily basis and actively pings you if there is a new vulnerability found, because that can take up to two and a half years. Few things I want to show you. I connected for instance a bunch of my repositories from GitHub to in this case my sneak UI. This is spring goof, exactly the same thing I showed you earlier. And it will scan my repository on a daily base and shows me if there are problems, for instance, and what is the priority score like which one do I have to help first? And these are interesting facts that you can help. And because it's scanning on a daily basis, you see last recurring test 5 hours ago, I can test it now, but tomorrow it will test again. I did it on a daily basis. So that is one thing. But also and this is a sneak peek of your own code because that code that you created is still something that is important. I enabled a beta for sneak code that we are launching. It's not yet in the free tier, but it will be soon and it does code analysis for you. So next to the scanning of your dependencies, which is a very very important part. It also says something like hey, there's a SQL injection in a part of your code. Let me just show you what is the issue. Well, I'm using a parameter here and I'm actually copy pasting the parameter into a literal string for a SQL query what I can use to do a SQL injection. So these are interesting parts. This is already there. It's coming up for the free tier. So I wanted to show you this. So what we mean is we need to get the tooling right to fit your needs. Not so much satisfy a tool because it says hey, there is an issue. No, take a tool that helps you, gives you information on what is wrong, how to fix it, and pings you in the correct way that you want to do that. So what we say is make sure that in every step of your development lifecycle you have security in place from the creation, from the thought process and the coding process on your local machine while you're creating it, to the production process by monitoring the stuff. Basically what we say, and this is a buzzword, shift left and left means as soon as left as possible in that previous thing I showed you. So start from the developer's machine already if you want to know more about best practices in code. So this was about your dependencies. But if you want to have more best practices on how to create good Java applications, or how to create good Java applications, for instance for Docker, visit our sneak blog. We have a lot of stuff on there, not just the tooling I showed you, but a lot of research we do and a lot of help that we want to get into the community to make you a secure developer. I want to end with this sheet. We're currently asking you to do a Java survey, and if you're able to, please go to the Java ecosystem survey and fill it in. That will be all. That was my talk. Thank you for watching. Enjoy the rest of the conference. See ya.