 I'm going to speak to you about five open-source security tools I think that all developers should know about. So first thing first, most of the developers that I know doesn't really care about security, at least not its first thing, right? So when they say about if their code is secured, most of the time they say, not me. I don't know how. Or something else doesn't really relevant. And so why does developers need to know about security tools? So hi, my name is Ron. I'm a developer team leader at Jeet. It's a product security company based in Israel. Startup, we're still very small. I have 10 years of experience in managing rules. I started at the IDF in a unit A200. It's similar to the American NSO. And I was there for seven years. Then I joined a cybersecurity startup. I was the first employee and one of the forming team members called BDEM. They were acquired a year ago by Datto. And then I took my back-end skills to the limit. I moved to UpsFlyer, if you know it. It's also Israel, but it's already 10 years old. And they're doing mobile management. My team was responsible for 100 billion events a day. And even though I come from some cybersecurity background, I consider myself as a back-end engineer. I was mostly in infrastructure and middleware. And even myself didn't think about security first, thinking about performance, functionality, user experience, even cost, and only then about security. So I joined Jeet to help all developers know security better. And I will show you what you're doing at the end. But first, I'll discuss to you about all the five security tools. Why do I think that all developers should know about them? Why do you need to secure? How to choose the right tool? And a demo, if you'll ask till the end, I will show you also what Jeet is doing with all those security tools. OK, so why? So we believe in a term, it's a relatively new term, called Minimum Valuable Security. Like you have Minimum Valuable Product. Probably you all know about it. So we think that like the product, it should be also in security. You have to start early. Don't wait for a breach to happen, or for the CISO to come and start asking questions, or for the company to do some compiling, like SOC2 and things like that. You have to start as early as they can. And shift left. So I'm sorry. I've heard it a lot of time in this convention. So I think that this is the future for developers. I mean, up until years ago, developers needed DevOps teams to start servers, to do a lot of ops operation. Now they can do it by themselves. They can raise lambdas, servers, whatever they need. Also in QA, they can create end-to-end tests by themselves. So I think the next thing is security. There are a lot of companies in the recent years that are starting to do this shift and give the developers the power to secure their code. So with a lot of power comes a lot of overhead. So they have to do it iteratively, not doing all at once. Let's say they didn't start early, and the project program is running for years. If they want to do it now more secure, it can take them a lot of months to do it. So we're talking about doing it iteratively. Next thing is, why do you need to secure? So those are just a few of the categories you need to secure. You need to secure data to protect from any secrets to being leaked. You have to secure your libraries you're using, the infrastructure for a cloud infrastructure and everything else, your containers, and runtime scanning. So how to choose? So I told you that, indeed, we want to help developers use those security tools. So actually, research and invested a lot of time to research different tools in different areas that they show you before, and also in different languages. And I won't show you all the spreadsheet with all the thousands of points. And I'll get only the three main things you have to consider. So the first term is accountability. You're searching for a dependency check for Python. Start looking for an open source tool for it on the web. Get to GitHub. You see a couple of options. So you have to check the stars, how many watchers, is it owned by someone private or by a big company, even a security company? Does it have a lot of contributors? Does it qualify by OpenSSF? Is it maintained? Was the last update a year ago, month ago, or days ago? And the last thing, is it really free? I mean, is it MIT, Apache? Do you need, do you have any rate limit? You get only some of the data free, but then if you want to see explanation about the vulnerability you have to pay. So this is the first thing. You have to check. Okay, next thing up is usability. So this one gets even trickier because here you have all the data, you can search everything, now you really have to try it. So try it. You can, if it's got a good documentation, you can run it locally. You can maybe use a Dockerfire to run it. Maybe it has some plugins to IDE or CI actions in GitHub or Jenkins. Does it configurable? Does it need files or flags to run it? Is it easy to add all those flags? And how does it output looks like? Is it a JSON file that you can handle technically? And is it easy to understand all the parameters? Like if it found vulnerability, does it show you what it is and explain all the details? And the last part is actually the hardest part. You have to actually run it and see the results. So you can test it on your own Ripples, on GoTriples. So here we have actually some cybersecurity expert, better than I am, that actually checked them on GoTriples and see if it has a lot of false positive or false negative. And does the severity level is accurate? I mean, maybe it shows everything is critical, but some of them is low. So it's also a lot of overheads to the developers. Does it have a good coverage? It can be on file types or maybe just more databases that it connects to and get more CVs. So that was the part. And now after we discussed about why, what and how, let's start and deep dive to each one of them. So secret detection. Okay, talking a bit fast, we'll slow down. Okay, so secret detection mission is to find secrets, passwords, even credit card numbers, API tokens, all kinds of secrets that you don't find to get to the web. So by the raise of hand, who knows someone else that pushed a secret to GitHub? Someone else, not you. Okay. So it happens all the time. Not to me, of course, someone I know. And we checked three different tools for secret detection. So we checked GeatLeaks. Actually, a couple of days ago, we announced that it's gonna be a company. It was by Zachary Smith. And it's gonna be GeatLeaks company. So I updated. We checked the tech secrets by Yelp and GeatSecrets by AWS, all our great tools. And we did all the checks that we talked about. And we decided to go with GeatLeaks. It gave you the page from GitHub. You can see it has a lot of watching and forks and so many stars. And it was updated a couple of weeks ago. You can run it all so many options. I mean, directly for your computer, it has the CI action. Actually, I think that now the CI action you have to pay for, now that it became a company. But you can still run it free locally and in Docker file. And it has a good config file that you can add more rules, more regex if you have secrets that you know how they look like. It's very accurate. We saw that it found a lot of our secret. You know, growth repos, not the real secrets. Of course, we don't have them. It runs on all file types that we checked. It can be a text file. It can be Python file, Terraform files, everything. And it found a lot of secrets from different types. I mean, AWS account keys, GitHub account keys, all sorts of secrets. So I'll show it just an example of how it looks like. So this is an access key for AWS. And if you run it simply writing the command at the top, it founds the secret and it also tells you the rule type. So this one is AWS access token. Okay. The second category is dependency check. So what's the mission? To detect open source component with known vulnerabilities. Even it's the first packages use or even deeper packages that they use themselves. So we checked here specifically for Python. We are design partner zero for our company. So we were writing Python, so we checked on Python and we checked safety by PyApp, Jake by Sonotype and dependency check of OWASP. All were very good and we chose OWASP. Also it's very, very common tool to use. It's also passing the open SSF. It's very update, probably 12 days ago since I took the screenshot. And you can run it also in Docker file from the terminal that's a Jenkins plugin. I put it in purple because I don't want to put in red so you don't think it's vulnerability. But not such good thing. It doesn't find the dependency tree. So for Python it doesn't really matter but the dependency check also can run on node and on Golang and they can find you a library that you use deeper but it doesn't show you the tree of what was the first external library that you use. So you have to use some other tools to get the tree and tend to cross between the results. It's very accurate, it checks the vulnerabilities both in NVD data and OSS index. It runs for Python, it runs actually not only on the requirements, sorry. Also runs on zip file or metadata file other places that can have Python dependencies. And it runs as I said on multiple languages and not only Python. Some of them are actually are in experimental mode. So actually for a go we choose Nancy and I won't discuss about it but it's such a cute logo so I put it here. So yeah, you have to really check for each language that you use if it's good for it or not. For Python we found out that yes but not so for other languages it depends. And they keep processing it and keep updating it we will see updates all the time. Okay, so an example I have this big requirements file with only one library, requests and you see all the output but I'll zoom in. And so it found that it has a vulnerability inside it it tells you the CDE from OSS index and it even gets a score. And what happens with this package actually this one sums it up insufficiently protected credentials and can even go to the site and get more data from OSS index and for more site. So point number three infrastructure misconfiguration so what's the mission here? So we wanted to detect misconfiguration in infrastructure as code before it hits the sky, reach the cloud. It can be misconfigure, missing inscriptions to broad permissions. Maybe you are not logging which is actually essential in security or not using other mandatory things you should use. You have some default ports or any other default values that you shouldn't use. Let's check the picture. It tells me to slow down so it's okay. Okay, so we checked TFSEC by Aqua, Kicks by Checkmarks and Chekov by Palo Alto. I think all of the booth here upstairs all were very, very good tools and it was really hard to choose. We go with Kicks after a lot of testing and also very, very strong tool by Checkmarks. Very updatable stars and everything and it can run on multiple file types. It runs on terrible files for AWS, cloud formation JSONs for Azure and Google Cloud as well. It has powerful queries. I think more than 2,000 queries you can see on the website that he runs and scan and check if there is a vulnerability in your code. It does a nightly build so it can get updates all the time and the non-fileable scan is actually aligned from their output so usually when you run it you get a JSON file with all the data and all the vulnerabilities even if it didn't find anything. But if there weren't files to scan meaning there were JSON files but non-cloud formation JSON it gets you a text file with this output so it's not the only case. There are some kind of case when it not gets you the output you're looking for. So you have to handle it yourself and here's an example. So this is Amazon Elastic Block Store and this is the config for it and I'll zoom in. Found you the severity and medium level and it's essential to use encryption and it's not enabled. I wanna add something else compared to Chekhov which was also good and also gave us a lot of result. Chekhov didn't give us the severity level and this can be very overwhelming to get 2,000 vulnerabilities without any severity level you don't know which one are more critical than the others. So this is one of the reasons that we choose Kix and not Chekhov but both have very good false positive and false negative scores. Okay, container scanning. So the mission to find vulnerabilities in your containers images and the Docker files. So we tested Trivi by Aqua, Clare and Encore and we chose to go with Trivi. Also they have a boot upstairs I think of Aqua. Also a lot of stars and forks and it's very updatable, maintainable. And it's very, very easy to use. You straight out of the box. It's very accurate. It's trying to multiply all its packages if your Docker file runs in different packages and it also detects secrets and infrastructures as code vulnerability. So why is this lying in purple? Because for Trivi it's good. It does a lot of things but actually it is better for Docker files and we use the other tools for secrets and for infrastructure as code. So if we use Trivi as it is we will get actually duplicated findings and vulnerabilities from all the tools. So you have to configure what you want to get from each tool if it is configurable. So I didn't add the Docker file but I ran it on a Docker so you could find three vulnerabilities. Two of them is because of a long path name and the last one is runtime. So runtime scanning, you need to check your web application even your APIs while they're live up and running. It's also called DUST. So we checked between Zap by OASP Foundation, Nikto and Akini. I think actually they are already deprecated and Zap is a well-known tool. I hope you already know, I've heard about it. I think it's running for 12 years now and it's very, I mean, gets a lot of releases, a lot of contributors, passes the open OSSF, open SSF. It can be run in two types, full scan Docker. You can actually install it as an application and it has a UI and you can configure everything. It's very, very extensible. So it's got a marketplace, it's got a lot of plugins. So if you want to deep dive in it, there's a lot of work you should do to add more plugins and to use it better. And it's very accurate, it has a lot of feature. It checks for SQL injection, broken access, cross-site scripting, it does fuzzing, authorize and unauthorized access. So many, many tools and many things it can check. So here's just an example of finding that it found. The content security policy, the header is not set and it explains you the reason why it's a problem. It gets a risk score. I don't know why it's both low and medium. Okay, so I'll show you a quick demo of using only four of the tools, the first ones. And what can go wrong? Oops, okay. So here I have my repo, it's public and it's got a Terraform file using DynamoDB. And we have a Docker file, some passwords in it. We've got a Python file to run everything and requirements with some vulnerabilities. Okay, so it just configured a GitHub workflow called it security demo. And you can see here, I will zoom in. Okay, so I just wrote all the tools that we discussed about. It runs parallel in different jobs. So, secret detection, this is all it has to take in order to run. Actually, it runs only on the last commit. Unlike the others, we checks all your different branch. I'll discuss about it later. And dependency check. So this is always dependency check and everything you have to pass it in order to run. So this is for running on Python. Infrastructure is code, this is kicks running on the Terraform file. So it can run also in other file JSONs and a lot of things. They actually also added option to run on Docker. So you need to check it again compared to Trivi. But still we're using Trivi for checking containers and that's about it. Okay, so I will add and get up token because I love secrets. I saved it here and I'll create a new branch. Okay, so this is actually pushed my changes. I don't have to create a pull request. And it started to run all the tools. You can go in, then meanwhile, we'll create a pull request. So this is the secret scanner by Gitlix. So you can see how it works and it was found. It tells you the rule. It found out that it skids a password. This is just the regex for how GitHub secrets looks like. GHF and numbers. Okay, dependency check finished. So you can see it found, it ran a lot of checks and it tells you that it found the CVE. You can go to the report also to find it. They finished really by the order. And this is kicks and it found a lot of things of different severities. IAM access analyzer not enabled. F3 bucket logging disabled. And higher severities, Dynamo table not encrypted. Mf3 delete. So you can see it found a lot of things. Two high severities. It gets your conclusion at the end. Last one, it's still running. Okay, so part of the problem that some of them can actually take long time. Actually, I'm surprised it's trivy. Usually it's more kicks because it reaches database to get information and also dependency check. It needs to be updated all the time. And let's give trivy some chance. Okay, so it took time because it needs to update the DB every once in a while and it downloaded the DB and it found four high, sorry, and vulnerabilities and it explains you the reason why. So I mean, go back to the slides. Okay, so I show you how to run everything and we discussed about some difficulties that we have with them. I mean, not all of them. Most of them are pretty accurate but you have to add some takes time, some have different output files. So you have to handle each one of them and see how to use it. I still recommend if you're not using any of them and you're using Python or any other tool that we discussed to try and see it for yourself to just add them and see if it finds vulnerabilities. Another issue is unlike Gitleaks, they run on all the default branch and find all the findings since they won. And it also can be very overwhelming to the developer. You just write his small PR. I didn't want to see all the other files that they didn't touch. So we actually want to do an orchestration of those tools and to help you use them very easy and much faster. And those are some of the tools that we're running. So it goes for different languages and different technologies. Proler, for example, is for running checks to your AWS cloud. SEMgrep is for static analysis for JavaScript. Bandit is static analysis for Python. GoSec4go, we discussed about the cute logo of Nancy. Sorry. And we also added branch protection, checking your branches at GitHub to see if you enabled branch protection and more other tools that we're using ourselves. And I'll show you our tool in a minute, but these are some squinch tools. Let's just see them. Okay. Okay, so I already enabled a plan. Let me zoom in. So I want to check on my assets. I want to check static analysis, dependency checks, secrets, containers and infrastructure as code. You have service catalog to add more tools. You can see by plans, if it's SOC2 or OSP serverless top 10, by categories, and you can add more tools and more features. Some of them, we're still in beta mode, by the way. So some of them are not enabled, but you can use most of them. And I already committed the plan and I already added my repos. So these are all the vulnerabilities I already had on my default branches. So we do think that in these pages, not every developer will go and look inside because this is more for a security champion that want to go deeper and find all vulnerabilities and he can decide what to do with them to assign them to a team or to a person. But once someone created a PR, so this is for the developer, we're actually telling him where he added, this time a secret where he added vulnerability and we show it as a comment on the PR. And if he merge it anyway, it depends if they enabled branch protection by us or not. Oh, so only then it will go and appear here in the finding page. I'll give you time to run. And I think that's it. I spoke too fast. So you have 10 more minutes for questions or for a break, you don't have to ask questions. Yeah, go ahead. Jit, yeah. Like just in time. Okay. From different tools. Okay, so yes. So we're actually checking what the file extensions that were changed in the PR and we only run on Docker file trivy and on CloudFormation files and Terraform files kicks. So this way we won't get duplications kicks. I mean, tools get upgrades all the time. So kicks started also telling about secrets in the Terraform. We now do have duplicates on that, but we are going to fix it soon. And then we'll de-dupe them as well. So yeah, go ahead. Good question. I didn't talk about it. Okay, so another thing that we believe in it's security as code and plan as code. So actually when I installed Jit, it actually created this repo on my organization. And this is the only repo we have access to. We actually, all the checks are running on the client and we're not reading these files and can't access these files. So here you can actually define your plan as code and you don't have to do it from the plan page. And also the same security YAML you can define here with other parameters to run. You can change it for yourself. But these are default recommendation how to run this one is for Bandit for Python scan checking. And as I told you about, sorry, the secret detection. So we run it like this and this actually gives us not only the last commit but all the changes in the PR. Which it's really dependent. It helps us to get all the changes. So yes, thank you for the question. Any questions about the tool? I didn't manage to be mostly on Jit. So if you have any questions about the tool themselves. Yeah, go ahead. Okay, so actually we try to check between severity levels between different tools. We can't tell about every vulnerability if it's false positive or negative when it runs on your machine. But we do try to normalize all the severity levels. But yeah, if the tool is having false positive or false negative, we don't change it. So they can actually ignore it either from the PR. So I already merged it but you can actually ignore the finding. We wanna add more ignore your types like ignore all the tests or ignore all the folder. And you can also ignore it as a security champion after it reached the default branch. You can, oh, here we go. Those are the last one. You can actually also ignore it from here. To answer the question. Yes. So it really depends. We wanna add more types of ignore rules. So it ignoring a fingerprint and it can ignore in the future types. I mean the test ID, each test has a different ID. Or let's say you have a test folder in your repo and you want, there are a lot of dummy secrets in there and you don't want to text this folder. So yes. Questions? Yeah. I have to check. I don't know why not, but yeah. So it's not an open source but it's in a public beta, free beta. We just announced it like two weeks ago and we got out of stealth mode. And we do want some part of the code to be open source in the future or the way to wrap a tool and to handle the different outputs. So we do want it to be in the future open source. And but we do have a, actually, we work with Gitleaks and we sponsor them and they also use us for themself in Go. Good question. So actually this is my team responsibility. So we now only have like a simple copy, a way to copy the, sorry, all the fields and you can copy multiple findings but it copies them in a way that you can actually paste it on JIRA and it gets us all the fields. We want to do better integration with all tickets providers like JIRA shortcut and things like that. And yes, we're now started to work about remediation. First from dependency check, that's the easiest part and we moved on to start looking at infrastructure as code and infrastructure misconfiguration remediation. Still working on it. So if you have any ideas, we're gonna do it actually, I hope to do it from the PR. It will send you a suggestion and you just click on the suggestion and it will change but some of them actually dependencies check we want to run it scheduling. So I mean, maybe once you merge your code it wasn't, there wasn't a vulnerability and then something was found or deeper library was changed. So actually we will need to run dependency check every week or every day and you might find something afterwards. Yeah, so all the Upset tools on GitHub run on the client environment and other things like Proler that runs on the AWS cloud, we're on it from our Fargate machine. Yeah, yeah, it's like good questions. I'll add them to the slides afterwards. If you can run JIT locally, you mean? So we don't have it now, we'll think about it. Good idea. Okay, so thank you all and four times. So we have four more minutes to drink coffee. So thank you.