How do you secure your cloud native product on can ongoing basis? Probably using branch protection and some CI CD pipeline, right? You probably have multiple security tools, each one speaking its own language. You need to configure them individually and obviously JIT will be hard to scale, especially if you want to configure those tool in a different manner depending on the context, some repos being more critical than others. But what if there was a way to write simple policies using a single language for all your security tools? That would certainly make your job faster and less painful, right? Well guess what? That's not science fiction. Thanks to a great open source project called Open Policy Agent, which is exactly the topic of my talk today. I am David Melamed, co founder and CTo at JIT, the continuous security platform for developers. JIT provides a unique set of built in security plans as code, helping you navigate through your security journey by automating the integration of tools and processes. But back to OPA for those who have never heard of JIT or never used it, open policy agent is a cloud native open source policy engine whose goal is to unify policy enforcement across the stack. It can be used for a high variety of services like API gateway, message brokers, kubernetes, API server and CI CD pipelines. It provides a high level declarative language called Rego that lets you specify policy as code and APIs to offload policy decision making from your application. And the main use case for OPA are authorization, SSH, access, admission control and data filtering. Now this is a sample architecture using OPA. Here you can see there is a request to a service and in order to decide whether the user who made the call is authorized to call it and should get a proper response, the service dedicates the decision to OPA which leverages some database in order to get the mapping between the lists of the user and the roles and the policies which are written in rego that define the role of the users that can see the data. Let's see a concrete example of that. Here you can see a service called salaries that will return the salaries of the employees in the request. You can see in the header that the user that is making the call is user one. Now the service is delegating the decision of whether or not user one can see the results these salaries by calling OPA, passing the header, the X user, user one, and OPA will leverage both the data in the database that is mapping between the users and the roles. So here user one is employee and user two is admin and the policy which says that only admin can see the salaries. So based on the policy, the data and the input, it will actually evaluate the policy and says that well this user, user one should be denied and that's the decision that is returned to the service, the salaries which should deny the request. Now a little bit more generate about this regal language. Basically it's a declarative language, that is that the syntax is mirroring declarative real world policies. For example, is X allowed to call operation y on resource z? And you can see how it's applied here. The policy at the left says that if the method of the input is get the path include reviews and the user is John, then the decision should be allow. And as you can see in the right, in the input, the method is get the path includes reviews and the user is John. And so the results of this policy is actually true. Now if we apply this to the security world and let's see a tool that is here a SAS tool. So static analysis, then you can see the following. At the left you can see there is the JSON output of the tool called bandit, which is a sast tool written in Python. And this output includes some general statistics. As you can see at the top it includes the number of vulnerabilities per severity. Now in the right you can see that the policy says that if the totals of the high severity is higher than zero, then the result should be denied, decision should be denied. And as you can see here in the left in the output you can see severity high is four. And that's why the result is deny test fail with four severities. Now for the rest of the talk I will take a very simple Python microservice. This microservice written in Python is basically returning the time and is getting an optional time zone in order to return the time in another time zone than a default one and default one. Here is Berlin. Okay, as you can see the result is very simple and it's return the time with the time zone. Now what I want to do with this application is to apply some security tools in the CI CD pipeline. So basically these are the four tools that I will apply here and I will get back to the signification of all those tools. But I want to explain a little bit what we'll do in this demo. So basically the user is committing comes code to GitHub and then GitHub is generating some PR event. Because this is a PR in the PR itself, it will trigger the CI CD pipeline. Now for this demo we'll use in the CI system GitHub actions by GitHub. And what you can see here is that we'll have four different jobs. Each job will run different security tools. These tools at the end will have some output. And after running all those tools, we have another job that will run open policy agent that will leverage both policies that are written in rego and that are stored in a different repository, in a central repository. And the result of all these tools, and based on this input, so the results of all these different secret tools and the policies, it will decide whether or not the PR should fail or should pass. Now let's take a few minutes to get into details of each of the tools here. So the first tool is Bandit. Why do you need a tool like that? Basically, you want to make sure that you don't have any vulnerabilities in your code. So for that you will use a tool that is doing some static analysis code. And here you have bandit for that. SAS are here to detect vulnerabilities based on existing patterns in the code. And Bandit is an open source tool that is written in python and that includes 35 built in rules for detecting vulnerabilities. The next tool we'll use is called Gitlix and editext secrets I think I need to explain you to you why we need to detect hard coded secrets, and you shouldn't have hard coded secrets in your code. And so Gitlix is a great tool that knows how to search for a lot of different regexes of well known secret patterns like GitHub personal access token or slack tokens, AWS keys and so on. And it also knows how to search through Git history, which is very convenient because you may actually commit something and then commit another thing, and then you actually forgot completely about your secret in the history. So this is the second tool that we'll use. The third tool is has dependency check, and we'll use that in order to track third party libraries with disclosed vulnerabilities. It's very important to make sure that all your libraries, all your dependencies are sane from vulnerabilities. And dependency check is a great tool that is maintained by OwaSP and includes its own database for that. So this is the third tool that we'll use. And finally we'll use zap, which is simulating attacks on your front end to make sure that your code is safe. This web application scanner is open source. It's also maintained by OASP, includes most 20 built in rules, and knows both to handle web application and API using open API or swagger model definition for endpoint discovery. So these are the full tools that we'll use in this demo. Now let's talk for a minute about the two sets of policies that we'll write in rego and that OPA will leveraged in order to decide whether or not to make the PR pass. So the first one is for the SAS tool and as you can see here we have a package, package SAS. The package is actually collection of different rules. Here we have two rules. The first rule is basically saying that we don't want any medium severity and the second one is saying that we don't want any high severity. And if you're looking at the right you will see a sample of the output of bandit. This is what we already saw previously and he highlighted basically what this policy will be able to detect in the JSON that it will receive after running the SAS tool in the CI pipeline. The second policy that we'll write is about the secrets. And basically here we also have two different rules. The first rule will make sure that we don't have any secrets in this serverless Yaml file, and the other will make sure that if we have an AWS access token we'll actually fail the PR. This is really an example just to show you some rules. Obviously we'll probably prefer to make sure that if you have any kind of hard coded secret you will want the PR to fail. But here, let's say for example, you have a tool that is creating a lot of false positive and maybe you want to make sure that comes specific type of API keys you want to fail. And so this is an example of how you can write something like that. We're checking basically here that if the rule is AWS access token, then make sure to fail the PR. Okay, so now that we saw the different type of policies that we want to write, let's put it in action. So this is my ide and this is the code of my small serverless python application. There's a simple function here, get function that will return the current time based on the time zone, whether it's provided has a query string parameter or using the default one, which is Berlin. Here I also have a docker compose file because I want to test my application locally. So for that I'm using local stack and this is how we'll deploy my application in a few seconds. What I also want to show you is this secret Yaml, which is basically the GitHub action workflow that I will run both locally and after that I will run it on GitHub. So as you can see here, and as I explained before, I have a couple of jobs. So I have a job for the SAST tool, I have a job for the secret detection, for dependency check, for the dynamic runtime detection and also this policy valve that will run policy agent. So first of all what happens in the SAS job? Basically it's running on Ubuntu latest, checking out the code, setting up Python, installing bandits and just running bandits, saving the output in the JSON file and after that uploading that as an artifact. The second job, the secret detection is using this Gitix action and is saving the report in a simple file. And I here need to use low and secure commands in order to be able to save this file inside this action at the end I'm writing this report here and I'm also uploading as an artifact so that I will be able to retrieve it afterwards when I will evaluate the policy. The third job is dependency check and actually it's similar. I'm checking out my code setting up go here and I'm installing poof, which will allow me to parse the result of the dependency check. Here I'm installing dependency check, making sure that I'm using also some cache for a database so that it won't retrieve the database every time. And at the end I'm running the parentheses check tool and I'm saving the results in some JSON file. The DAS tool is a little bit more complicated because what I need to do is to deploy my application to a local stack that is running inside my CI and after that I can run zap against this public URL that I will get. So this is what I'm doing here. I'm getting the results here of the deployment locally to local stack and then I'm running zap against this URL. So now that I have all this for job running, at the end I'm running the policy valve and what Jit does basically is that it's retrieving all these two sets of policies that I defined earlier from this repository it's using comes test which is a tool that is running behind the scene open policy agent and then I can retrieve the different artifacts that I downloaded. I uploaded, sorry. So here it's retrieving the bandit report and here it's making sure that the policy, so conftest, which is running OPA behind the scene will make sure that the bandit report will actually comply to the policy of the SAS. And after that I'm doing the same thing for the other policies. So here are the secrets and I'm also making sure that contest runs with the report against the secret packages. So this is basically the code and I will see that in actions. So I will go to the terminal and here I will just call again here this ping to make sure that my service is working. And then what I will do is I will run act, which is the local version of GitHub actions, just to show you that I can make it work locally first before going to GitHub. So let's make it run. As you can see there are some secrets that Gitix found and it's now uploading the artifact, installing everything here. And in a few seconds we should have the results. We are also already running the policy evaluation. So here we are retrieving conf test as an image. Here we're retrieving the policy from this repository. And here you can see that two tests were actually run, one passed and one failure. And that's because I had some vulnerability that Bendy discovered. And so that's why it actually failed right here it's actually written SAS test fail. Why? Medium severity. Right. Okay, now let's see how it works in GitHub itself. So for that let's go to the browser. This is the repository that you can also clone and that include all the code that I just showed you. I have another repo for the test for the policies, sorry. So here you can see the policies that I showed you before, right? And here if I'm adding some, changing something here for example, and I'm creating a pr and then we can see the results here. Actually I already did that before. So we can see here that all the difference job ran and at the end the policy evaluation failed. And if I'm getting here the results, the details, I can see also the same thing here, that bandit actually failed and I can see the details if I want. Here I can see the details that I have one medium severity. Right? So what you just saw in this demo is a way to manage centrally policies in order to have a single way to write your policies and a single decision point. And Ajit, we implemented this as part of our platform in order to provide a simple way to manage the open source security tools that we orchestrate in the context of the security plans that we offer. And of course you can imagine that you can write more complex rules per package and even you can add things like external HTTP called if you want to other services in order to make things more complex, or if you need additional data from other services, or from database or whatever, you can make things really more complicated. And at the end, OPA will decide whether or not your pr should pass or fail. If you got intrigued by what you just saw, just like don't hesitate to visit our website and try out the early beta version of our platform in order to start securing your project. And if you write me a message, then you will even get vip onboarding experience. So I'm welcoming you to try it out if you like both the idea of having some kind of central way to manage your policies and to manage all your security. So thank you very much for your attention and if you have any questions, don't hesitate to drop me a message. Thank you.