Whatever problem you want to solve, these are hundreds of potential open source tools that can help you. Some are better, some are worse, but when it comes to security, you don't want to mess around. We at JIT build a security platform that leverages open source security tools in order to figure out the best ones we needed to go on a tool checking journey. I would love to share that with you. Hi, my name is Avi Ram. I'm co founder and chief product officer at JIT, which is a continuous security platform for developers. What this means is we help dev organizations build secure applications from day zero by automating security plans using open source tool that we have curated. We have researched and tried hundreds of tools to choose the best ones for our needs. We tested the tools on real projects and got real results. This means that we are very much familiar with various open source security tools that the market has to offer and I would like to share insights with you and generate interest among you regarding these tools. There are many properties we use to rank the security tools. Here are some of them. We want to see a tool that actually detects what it should true positive rate high true positive rate and that it has low ratio of false positive. We want tools that are easy to use. Their output makes sense and the tools in general should be easily integrated into these. CI we want a tool that is supported by large communities of developers and that in general is maintained on a regular basis. In terms of ownership. We see some advantage when there is a prestigious company behind a tool because it creates a standard. In terms of GitHub stacks, these stacks are a good indicator that the tool is popular. We also consider that as one important property and also licensing. We want tools that are free and we have some preferences to permissive licenses such as MIT and Apache. These are the security categories that we will focus at. These five, though there are many, I believe these five categories are a good starting point. So let's start with dependency check. The mission of dependency check, also known as SCA software composition analysis, is to detect publicly disclosed vulnerabilities in project dependencies like packages, libraries and so forth. In our list of contestants, we have three tools which all of them are good retire, JS, OS dependency check and NPM audit. All of them detect code vulnerable dependencies. We decided to go with OS dependency check. Yeah, that's because of few reasons. Usability is super efficacy is very good, high rate of true positive yeah, there are comes false positive but very good. Very good rate of true positive. It's very easy to use and it's also very popular tool, so we recommend using it. In this example we see that there is a dependency named ADM zap. It's a JavaScript implementation for Zip, data compression for node JS and it is used in this project. The dependency I'm telling you in advance, the dependency contains vulnerabilities. So let's see how OS dependency check faces that. So you can see these is the output of our dependency check and it identified that this dependency day ADM Zip is associated with three cvs with severity level of critical okay, let's move on to the next category, which is secret detection. The mission here is to detect hard coded secrets in various formats. So this could be password, ssH keys, AWS credentials and more. The tools do that by employing regular expressions, many various regular expressions and by calculation of entropy. We compared between three tools git secrets by AWS labs detect secrets by Yelp and Gitlix, which is owned by individual developer. All of them are good and free. We decided to go with, so we chose Gitlix. It detects hard coded secrets like password, API keys and tokens in local and GitHub repositories, private and public. Some pros for Gitlix very good detection rate. It's very easy to integrate to the CI. It is developed with almost 100 contributors and it provides reporting in various formats. When compared with the other two tools, we prefer to go with Gitlix even though the others are good as well. So this is an example of a key and this is the output of Gitlix. You can see that Gitlix identified these secret and associated with a rule that is called AWS access token because it obviously matched a regular expression built for AWS access token structure. Okay, so the next category is terraform scanning. The mission here is to detect security vulnerabilities, cloud misconfiguration issues and all that by analyzing the infrastructure as code, which is very important. Security capabilities security capability for those of you who work with infrastructure as code, we have compared many tools. The top were check by bridge crew, now Palo Alto Kix by checkmarks and TFSec by Aqua Security. The good news here is that all tools are great. They are backed by good companies and they constantly improve and they do their job. All of them, by the way, are either MIT or Apache. Matwizi decided to go with Kix and that is for two reasons. First, Kix has exceptional detection rate that we love and the other reason is that it includes indication of severity, which is very useful for prioritization for DevOps people who are not security experts. So the indication of severity was for us an important property of KiCs. So in this example we have a terraform model where EBS data is not encrypted, as you can see in this example. And Kix identifies this misconfiguration and ranks it as medium, together with sharing detailed description and guidance how to fix it see medium and the relevant description. Next category is the runtime scanning. The mission here is detecting vulnerabilities in web applications while they are running. That includes also API scanning and it can run in a nonauthenticated code, what we call black box testing, or authenticated mod, what we call gray box testing. The contestants here were OWASP, Nikto and Arachni. All these tools can help you evaluate the security of web applications and each of them has above three k stars so they do their job and they are popular. In this category we decided to go with zap. It's a very popular open source Das tool. It is container by the Ops Owasp foundation and has been around over a decade. We chose it over the others for these reasons. It includes authenticated and non authenticated web app scanning. It includes API scanning. It has good range of features like vulnerability scanning, fuzzing reporting, and is well supported by a large community. In this example, Zap scanned a web application and detected that the content security policy CSP header is not present in the server response. Essentially, the CSP is used to prevent cross site scripting, click jacking and other code injection stacks. So it's great that Zap identified it. And final category for today, container scanning. The mission here is to detect vulnerabilities from all sorts in container images. We reviewed and tested various tools, but two topped the chart trivy by Aqua and Claire by quie, now part of red hat. We decided to go with Trivy due to its efficacy and easy integrated with the CI. Here is an example of output when Trivy was scanning a docker image that I created based on Debian 11.3. So you can see that trivy identified the vulnerable library. Now let me show you a quick demo about integrated these five security tools into the CI pipeline. I'm using GitHub and GitHub actions and you can view the demo repository in this link I created. So first let's take a look at the workflow file. So you can see that the workflow file, the jobs here are triggered by push. Okay, and these are five jobs here, one which deals with secret detection. These we run Gitlix. The next one, the dust, the runtime scanning, we use zap. For the infrastructure code scanning, we use kics, for the FCA we use dependency check. And for container scanning we use three d. All these jobs run in parallel whenever I commit a new change. So let me do that, I will just add a space here, commit a change. And you see that these workflow kicks in JIT. So you see that all the jobs run in parallel. And I see that secret scanner finished. So if we drill down, we can see that what we can see that a password, a secret was detected in a file named Docker file. The secret itself does not appear here, but you can see that JIT gitleaks actually detect the secret. And now you can see it gives also the line number, line eight. So if we'll go to the docker file, line number eight. Cool. So we see that dependency check also finished. If we drill down, we will see that the report was uploaded and show you later on. And container scanning also finished. So we see the detection of Otrivi in here, the dependency check. This is the dependency check report that all dependency check created. And this is the report that's upgraded. And let's see also the infrastructure scotscanner in here you can see for example that Kics found dynamodb table not encrypted, it gave it medium and provided some details about JIT. And also the alerts also appear here as annotations. Cool. So you have access to this repo, you can clone it and play with it. Okay, let's go back to the deck. Okay. Like you see, there are plenty of excellent open source tools that can be used. Yes, even for things as important as security. And it's very possible to build an entire security program only by using open source solutions. At JIT we took it into the next level. We enable users to manage a security plan and fully automate it with a continuous security mindset. We do that in conjunction with providing a dev native experience by adding comes inside the pr. So developer can have a great user experience more than just drilling down into the output of every tool in the CI itself. At JIT, we automate security plans and provide a great dev experience. So that's about it for today. I hope it was interesting for you and thank you very much for joining.