 Hello everyone, welcome to my talk on practical guide to CICD security gating. Just a small introduction before we go forward. I'm Ben, CTO and co-founder at at Armo. I'm one of the maintainers of the Cubescape project. I'm relatively active in CNCF and different technical advisory groups around Kubernetes and CNCF itself and in general open-source enthusiastic and someone who comes from the security background. So let's just jump into it. So I'm representing here two organizations or two things. One is Armo, open-source security company which is located mainly in Israel, but we have employees around the whole world. And we have around 40 employees. On the other hand, I'm also representing Cubescape. As I told you, I'm one of the maintainers of Cubescape. It is one of the most fastest growing security tools around Kubernetes. I should have updated this slide. We are beyond 9,000 stars in GitHub and we are in CNCF sandboxing and hopefully we are going to be in incubation in 2024. So you know today and in this conference, it's really funny to talk about world without CICD, but you know, just for the sake of the talk and sake of what we're going to talk about, it's just like really important to think a little bit about what is what would be the world today without CICD and automation. And it is it is, you know, it's really hard to comprehend today. It becomes so embedded in the industry and in our way of work that today it's really hard to think world without it. Having said that, I can say that I have like experience of nearly 20 years in the industry. And you know, this wasn't always as clear as it's today and even, you know, 20 years ago, we had some processes around and we were, you know, trying to automate a lot of things, but it wasn't articulated in a way today. And you know, every one of us knows this really great diagram of explaining, you know, what is CICD? The way that we are, you know, implementing things and building things and then testing them out, releasing them, deploying, operating and monitoring, and then, you know, getting back to coding. And these things are today are so intertwined and so overlapping, even, that we even sometimes can't comprehend it. And even in this, you know, in this great event we are having right now, this is one of the major things that have also evolved during this time, during the last, you know, five to ten years. And even today, we can understand that most of the things are going in peril. They are happening in the same time. And the whole idea behind this is simply, you know, freeing up and empowering us to work fast, to deliver fast, to react fast. And one of the funny things that I've been talking about with someone who is being auditing our company is, for example, that what's happened to release notes, what happened with delivery packages, and our whole approach to these kind of things has changed. And this is just only one example. So the whole idea of a CICD pipeline is actually to manage the whole process. And if we are adding the, you know, security into the, you know, to the goals of our deliveries, we're also looking into how to reduce the risk involved in deploying software, right? So it is like very, this whole empowerment is, is, is awesome. And it is like, I think one of the ultimate goals. But on the other hand, you know, with, you know, with great powers, you know, becomes great responsibility, we also have to include security in this process and planning things out of time. So let's start with, you know, us having the source code, you know, somewhere we work with, even if we are talking about source code as software, or if we are talking about configurations, infrastructure as a code. It's, it's in GitHub, or on the other provider for that sake. And there is some kind of a CICD server. Again, it can, today we have a great, very, you know, dominant approach that, that sometimes the CICD, or at least the CI part of this, of the process is also located in the same place where we are storing our code. This not, this wasn't necessarily true for a very long time. And even if not today, not today, this not necessarily thing, it can happen. It's a good thing. And you have to obviously choose what's best for you. But as a result of our processes, which are running on our source code and the CI process are ending, we are building artifacts. The artifacts are ending up in our, in my example, in some kind of container registry. And from there on, we are deploying things into our destination, where we are actually serving this, these functionalities from. And at the end, obviously, we need to monitor what's happening there. And we have all these tools, which I mostly, you know, I'm pretty sure that most of you are pretty aware of all these tools you see here. And they are, each of them has its pros and cons. And you know, it's really not my place to talk about what is good for you, but it's not. But these are, you know, most one of the most prominent things to discuss here. But the interesting thing here, which I wanted to tell you about is that, you know, developers are today much more involved in what's happening, you know, what we call shifting right on the right hand on the monitoring part than they were before. It was, you know, again, going back 10 to 20 years ago, it was really hard to think that how the developers have direct access and effects on the installation parameters of a software. And it doesn't go through a lot of, you know, manual labor, system engineering, this thing. And today, these things with all the velocity we've involved in our processes, this has changed. So, sorry, just getting back here. So if I want to draw up a little better, you know, example, and I'm, you know, as someone who's coming from mainly from the Kubernetes world, okay, it's really hard for me not to bring here Kubernetes examples and Argo. But in general, you know, this is true for many, for different other kinds of deployments, so please, you know, take this into account. So we have a developer, we have developer, a DevOps engineer who is, you know, working in the top left part on the source environment. The applications are delivered, then the CSC processes are building and testing, they're bringing into container registry. Container registry then, you know, using our favorite GitHub's tool is making sure that, you know, when we are giving the proper commands or definitions in our Git, GitOps is pulling these, all these artifacts from the container registry and delivering it to our favorite cluster container orchestration tool. And from there on, we are going into what we call monitoring mode. And we are using monitoring tools to understand what's happening right now. So this is like a very, very neat and nice definition. And I think that it's something, you know, we could be very proud of, we could be very happy. And, you know, the question is going, okay, what can be wrong here? So there are a lot of pain of points from a security perspective in, and it's not just, you know, to this setup, which I showed you. But, you know, through this setup, we also have to be very mindful of these issues. We have to make sure, okay, that the configurations are okay, all the definitions of the applications are okay. They have done to use new security risk and also even hardening our existing environments. We have to make sure if we are like a little bit going back even further back to the application development phase, we also might have to make sure that application is being, you know, implanted according to security best practices, and all the input checks are in place. But we also have to make sure that there are no vulnerabilities, which in our supply chain, which we are pulling in, checking in for, you know, any external third party things which we are using in our application, you know, even in in-house deployments, you know, as today described more than 90% of the code is usually coming from a supply chain vendor, which can be their open source or close source project. But in any how, it is something, you know, they have to be mindful what kind of security risk it involves. We have to make sure that all the, in case of Kubernetes, there are bug configurations are okay, that all the access control definitions are in place. And, you know, also we have to take this whole thing into account of when we are in production, all the definitions are right for production, we have forgot some debug on. So these are, you know, a huge bunch of things to be mindful. And obviously, you know, we are here to talk about how to tackle them. So, so we have to be very mindful of shifting the security as, you know, left to as possible, making the developers, and sometimes even devops engineers very mindful in their processes about the security. And, and there are multiple parts of the security and security has to be deployed across this whole system. And we'll see how. So, obviously, when the security is shifted left, we have to make sure that the security is tackled on the earliest stages when it in a development life cycle as possible, just as with other, for example, functional testing, you know, we know that from functional testing, everyone knows that, that, you know, we can have end product tests and system tests. And beforehand, we can have component level tests and unit tests. And, and the most important part is for the developer, even before he pushes his code into the code repository, is to check that all the units that tests are passing a passing. Why? Because it is clear that it is the cheapest thing to do, the cheapest thing to solve. Now, if the developer is shifting, if the developer is rapidly deploying and shifting right, the security have to shift left. And again, shifting left is very important because detecting the security issues on the pre deployment and on the deployment is very costly. It is just the same as functional testing. You have to be very mindful about that just as with functional testing. And today, everyone of us knows that as the sooner we are detecting functional problems, the cheaper they are to solve the same goes with security. So, where is the first thing where we can, you know, detect changes? It is actually, sorry, going back just for a minute. So, where is the first thing, where is the, you know, last, you know, chain in the, in the whole process where, where we can detect security issues is actually obviously in the deployment. So, in the deployment of our cluster, we can detect vulnerabilities using any kind of open source projects. And, you know, Aquast 3D project is a very well known project to do that. Cubescape is also doing that. Claire is doing that. Everyone has its, you know, advantages. And also, you know, my misconfigurations, checking that all the configurations are in best practices. And you have multiple projects to do that. Cubescape also does that. So, for example, you can use a cluster of vulnerabilities scanner, for example, GRIF, also to list all the vulnerabilities you have. Obviously, it's an overwhelming and if you're looking for all my previous talks in Linux Foundation CNC, if you will hear a lot about vulnerability management, but let's go a little bit further. So, if we're going a little bit a step back, we will end up with seeing, you know, container registry, how we're dealing with with container registry scanning. And, you know, there can be again, multiple tools of doing that. Today, you know, both 3D gripe and other open source security scanners are able to do that. Also, Cubescape. But, you know, in your artifact repository, most of the newest containers repositories can also provide you with scanning. But, you know, let's go a little more later. Let's see what's happening in the CICD processes. So, you know, you can scan your code and your source code with scanners. Most of them are closed source. There are some open source examples. But, you can also scan for vulnerabilities inside the CICD processes, which is again, is bringing the things more left on the side. So, for example, if you are adding a CICD process of scanning your application for vulnerabilities or misconfigurations, you can add a GitHub action, which will simply do that, scan for vulnerabilities and scan for misconfigurations and do that in a very early stage. So, if there is something, for example, misconfiguration you detect, which is, for example, giving a container privileges beyond, you know, what it's needed, you can stop it at the PR level, which is very, very important. Because, again, someone who is opening the pull request can auto-fix the thing or, you know, just make sure that they are standing in the quality. And, you know, you can have all these tests in your CICD pipeline, which is very good, because you're stopping these things very early. So, it is very important to focus your efforts and that blue box part, you know, trying to bring into their PRs, both from the application level and with vulnerability scanning, when you look, use some kind of a source code security scanner. And also, at the infrastructure code repository, use a scanner to detect issues. But even before then, you can also embed many security checks into your, to the step before, on your developer machine and find them out at that stage, so it even doesn't get to the CIC process. So, in the source code world, obviously, you have, you know, a lot of security plugins in your IDEs, you know, we've brought here a few examples. But you can also have, you know, the very well-known names, like SNCC and checkmarks and white source, which is re-branded mend, which can be used to scan and find security issues at very, very early stage. And, you know, also in, you know, your most, you know, lovable ID, you can also already have your comments there, just like in this example, and showing, you know, that there is some kind of an issue, which can be exploited in an attack. So, last but not least, obviously, monitoring is very important. It is very important to have monitoring and seeing that still everything is going right in your production system. And at the end, I want to show you this picture. You can have multiple security gates in your whole environment. You can have security gates, you know, obviously at the deployment phase, you can have pre-deployment phases, although I would say in the registry artifact stage, you have in the CIS process, and you can have also already in your developer phase. So, obviously, cyber is a risk and there is, there are a lot of things which can go wrong, but you can, you know, use the automation empowerment of all these tools to make, you know, less risk and make sure that you have less problems in your environments. So, thank you very much for attending this presentation, and I'm here in the chat for Q&A. Thank you.