Hi, my name is Roman Zhukov and I am from intel. Today we are going to talk about how to fit SeC into DevOps, probably without security team. Let me start with a mandatory disclaimer. Sorry about that guys. Today I'd like to express my own opinion and my own experience that doesn't necessarily reflect the official views or opinions of my employer. So I'm going to just share with you some public examples and cases. So there is neither confidential information today nor marketing stuff, only practice. So some links and names on my slides may seem small, but don't mind it please. Everything is clickable. My plan is to share slides with organizers so that you can follow them offline, if you would, and without any further delay. Here we go. Let me introduce myself real quick. I am practices cybersecurity expert with more than twelve years experience with the most recent area of my interest in product security and broader end to end secure development lifecycle well known as SDL or SDLC. Formerly I also brought to market new cybersecurity products services, manage complex security projects, consult firms like banks, telcos, retail, you name it. Also, I conduct classes at universities and private centers. In my spare time I do volleyball. I'm fond of hiking, running bikes, swimming, and basically of every single sport that is easily feasible. Okay, not for advertising purposes, but satisfying everybody's curiosity. Probably you might think why the silicon company talks not only about hardware, right? Intel and software. What is all about? Intel actually DevOps a lot of different proprietary and open source software products, including actually industry pioneering confidential computing products like SGX, Project Amber and ET cetera. Also we are providing some, as I mentioned, open source stuff, even in security space. And I will share with you along with other open software. So what we do and what we share with community, actually, maybe you don't know, but intel over the five or more years top four contributors to open source according to open source contributor index. So along with other respectful companies. So we know how to do software, we are consuming software, we are running of course our own devsecops practices. So that's why we can talk about that. Okay, let's start with myths breaking. Actually, I believe if you're for example, an RND or it professional or SRE or DevOps engineer, right? You may likely face some concerns about security or even struggle with your own company centralized security team, right? And you know what? I can't blame you guys for that, because let's say classic or traditional security approach doesn't really fit well to software development, to development departments or it specific companies that's true. Let's admit it. In all of these areas, baking security into DevOps actually can help. Let's see, five myths as you can see on this slide, right? Security team and their tools are aliens for RND. I think that is maybe clear for some of us. RND has their own KPI, right? And I heard a lot over my practices about how can we establish these trade offs between security and feature development, et cetera. We don't need to do that. We are going to make the robust and best quality products in the world. So this is all connected, no trade offs, no conflicts. Of course, if you do it properly, it is yet another vulnerability, right? Why should I care about that? Nobody will exploit that. It's not going to work. It's yet another myth. I mean, the fourth one, security doesn't contain good metrics or clear value or clear benefits. It's not true. If you do right security and you fit SEC into your development and DevOps practices correctly, so you are going to take these benefits. And the last one, my lower one, security is boring and unnoticeable for everybody. It's not truth. Again, security is really exciting, even for, let's say, ordinary engineers, not security guys, because the right security, the proper security is mostly about the technology, right? Of course it contains some compliance part, but it's also about technology, about inventing new things. Please leave me. Today I'm going to provide you with four, remember this number with four practical recommendations that could probably close 80% real could security problems related to development. Let's talk about benefits, actually what SAc in DevOps protests and modern development practices can bring to the business. This is definitely increasing time to market faster development. So security, along with all other DevOps practices, speed up development. It's scaling, definitely without properly including seC. It also will be the burden will be the only compliance, and it's not scalable flexibility. I will bring you the one example about flexibility a little bit later. Transparency. If you automate everything, if you have clear metrics and all this stuff, it will be transparent and predictable. And of course it's bringing trust and positive brand appeal and et cetera. If you are doing the good practices, if you support security. The only one example, I have a lot of examples, but in the sake of time, I will bring you the only one example of real value of fitting security into the modern development. Let's bring up the case study. I think this is kind of common practice and this is only one story, but we experience a lot of the similar story, right? The community unexpectedly discovered a critical vulnerability and extremely popular third party, right? Do remember lock for shell. Please rise your hands. Of course we remember this story. And if you are actually without DevOps, without security, properly integrated and automated, it takes you three days only for inventory. If you're medium or big company, it's really changing, right? To understand whether you really have this lock for j companies, right? And whether you're affected one week for auto cycle release, probably if you're a software company or for updating all your systems, because actually it's not so one time if you don't have security in your DevOps practices, additional surprise, you can find other third practices living for years in your code, right? That's a big deal. But with security, please pay attention at the right side of the slide. With security in DevOps, it's simple, thanks to implemented continuous security, right, we understand all our components so that we store logs, we can really quickly understand where we are affected, right? And probably even if we are big company, we're spending two to three days for out of cycle release for our software or for our services or whatever. Thanks to automation, thanks to SEC, properly integrated into the DevOps, that's a real practice, real example of benefits that security can bring up to your business. The most popular security box guys, this is a barely fresh statistic this year from the wear code. Don't really dig into the graphics, but I just prepared for you the outcome of this statistic that show top four most popular security bugs. I mean, they probably have been changing a little bit over the year, but anyway, this is again, buffer overflow. Underflow. We have been talking about that for over the years, over decades, maybe error and input handling, crypto implementation. All of this stuff appears, and appears as a bug, as a security problems that could lead to the real breaches, that could lead to the lose of the reputation and et cetera. So SEC into DevOps can help solve these problems. How we are going to do that in practice, right. The first advice, of course, to build up the full SDL or SDLC security development lifecycle. All this stuff, this is heavyweight, but if you're big or even the medium company, probably you must do that. For example, modern companies, the industry leaders like intel, build up their heavyweight systems. And I encourage you to take a look at the white paper, which is free, which is accessible supply chain threats made by senior engineers from intel. So there's a lot of considerations, including actually DevOps considerations and practice and recommendations. You can do that by following the standards, by following the industry leaders. It's of course the first thing that comes to your mind. But remember our topic, to build security and security into the DevOps without security team. So this is probably heavyweight. Still good practice, but heavyweight because usually when we start to think about security, you guys as a developers, as engineers, not really 100% security professionals may think, well, it take me, I don't know, years to integrate all these practices. I like this diagram by accelera because it's representing or summarizing the common 17 devsecops controls that you may need to implement to build the, let's say true heavyweight devsecops process and everything. But the thing is that small and even medium companies, for example, often don't have time or resources to do that, right? To implement all of that stuff. So I really encourage you to take a look at the points that really matters. And from my opinion that could you help to solve up to 18% of all security related problems or your security related stuff in your development cycle. On your flexible development process, you might ask what to do first, right? With the most valuable quick wins. That's why let's have a look at the practical recommendations that doesn't require actually a security team. At the nutshell, of course, it's good to have fully dedicated security professionals, but you can implement, at least at the certain level, these four recommendations without security team. And you remember what I promised you, four recommendations, but I lied a little bit. Sorry about that. Actually it will be four and plus two bonuses. In summary, six recommendations. Let's take an example, the GitHub. Let's turn back for a sec. These four recommendations will relate to static analysis, to software composition analysis, to roles and secrets, and to vulnerabilities scanning. Again, I pose that that is very important, at least if you are starting, because everything else could follow, right? Okay, let's return to the examples. These four areas could and should be covered primarily by your native development tools that you're really utilizing. I have been talking over and over again, like don't try to buy and to implement a lot of security tools, a lot of security stuff, of course, that's good. But first of all, please take a look at the native tools that you probably already have, right? If you're using GitHub, if you're using GitLab or other great development tools, please pay attention to its native security features. I bring up the GitHub not for advertising, just for an example. Again, GitLab and other stuff. They include their own security embedded features that you're going to use first, instead of trying to implement something alien, right? For stack analysis, GitHub has Codeql. For SCA, it has dependable which is basically a free and open source renovate bot. This is a great stuff for checking and automatically updating your dependencies. For secret scanning, this is yet another embedded feature and for vulnerability scanning as well. Part of that is free, especially for open source. For your open source project, if you are developing closed source proprietary some of these features, you need to buy the subscription. But again, please pay attention to embedded features because it will save you a lot of time not to try to implement something external. But firstly pay attention to embedded stuff that could be done without security team, especially stuff like dependable stuff like secret scanning and everything else. I mean that's simple. That's really simple. I haven't experienced to turn it on by the small companies and that cost nothing. I mean in terms of resources. Another example about open source and free tools. If you want to leverage not only your development environment and devsecops tools, you can use external tools. But there are a lot of open source stuff that I share with you right now. Please take it and use it. I put the asterisks here because not of this tool is free for everybody and for every case and for every programming language, but it's still kind of free for something. For example, Bandit, right? This is a native tool for scanning Python and this is free. This is not really static analysis tools, rather scanning for security practices. But anyway, this is native for languages. And when you're going to choose static analysis tools to scan your source code for insecure functions for all this stuff, I would suggest you to use the tools that's specifically designed for languages. I mean even, especially if you are looking for open source bandit, this is for Python, for example, rips, this is for PHP, samegraph, it's good for C sharp, go Java and eT are of course there are a lot of tools that, let's say support multilanguage, but some of them good with only specific languages. And this is great. I mean, one size doesn't fit. All right, for software composition analysis, the blue square on your screen, there are a lot of great proprietary tools, but you can use the free stuff. You can use open source stuff. For example, dependency check dependency track is fully free for understanding your bomb software, bullets of materials and vulnerabilities of your third practices that you're consuming, that you're integrating to your code for binary tools. Actually there are lack of good tools, but we at intel internally build the CVE binary tool. CVE checking for CV and we have open sourced that. Please feel free to use that for secret scanning. It's also not a big deal. So you can use Gitgarden, which is proprietary but still have a free plan for somebody it fits. Git leaks whispers this is free. Please, you use some special stuff for secret management. Again, this is all either open source or free. You can easily integrate that. And again, I intentionally brought up all of these tools because they're really easy to be integrated into your development processes without, let's say, a lot of specific security knowledge. Again, it's really good to have security team and to use their experience. But if you don't have any, these tools could be integrated because the most of them are really development centric, not security centric for vulnerability scanning. Of course we have a lot of free stuff. It depends on what you're really looking for in terms of vulnerabilities. But there are a lot of tools still available, even for free. Okay, let's switch to the first bonus. This is for containers and kubernetes. Again, this is small text on the slide, but it's all clickable so you can follow the links and check it out offline. Pretty much everything that we as a developers build up, guys we offer as a containers, right? Or even we build our infrastructure based on containers and use some kind of steering stuff like kubernetes or Openshift or whatever. So there are four key messages I wanted to deliver to you. Don't forget, of course, to secure your container on Kubernetes stuff. The left side of the slide represents the answer to the question, what could possibly go wrong in the container world? A lot of stuff could wrong, right? Escape from containers, leakages, escalation of privileges. There are a lot of real world examples. I don't have time to show all the real world examples. And it's happened again and again. You know, every single year we see some major breach, for example, or data leakage or attack or whatever, or ransomware even, right? Because of breaching container stuff. So first of all, select image responsibly, right? It's really crucial to understand what base operation system image you're going to use. Please pay attention and scrutinize and figure that out. That probably it would make sense to use scratch or barely scratch the operation system, distros, busybox or whatever. The second advice is utilize all, of course best practices when your code, when you write up your docker files, your configurations use official docker security guidance, use OASP cheap sheet, for example, when building containers from docker files, right? Run scanning tools and intel tools like headerlint for example, or Trevor or Taber, which could help you to understand your configurations. And this is really good, these tools. I'm going to share you that these tools are used by the major companies even because as the developers even we are really professionals, we don't have enough bandwidth, right? And physical ability to understand, to figure out all our code, all our mistakes. Please use this automation. Again, our today's talk is about how to integrate SEC into DevOps. Everything that I'm sharing today is easily integrated, is easily automated. Each single tool that's on my slide. So could be automation inside your pipeline, right? The next one verify secrets. That is clear. A lot of examples how secrets could squeeze into the yaml files container images through the different layers and then could be exposed to the public. Tokens, internal information, passwords, et cetera. Please pay automation to that. And the last one about containers. Consider runtime security when you are running your Kubernetes clusters, right? Use official Kubernetes security guides or openshift security guides or ranger security guides, right? Depends on what system are you using. There are a lot of hardening guides provided by state, for example NSA or CISA best practices or whatever. Please do not hesitate to implement the policy agent, the service mesh and everything that already exists by nature in kubernetes could and the last one, guys, I wanted to share, bonus number two, make all artifacts trusted. That is something that's advanced. I can say you are going to do that at the very beginning when you're just thinking about setting up your devsec ops environments, right? It's for more major companies. But I have to mention that because all of these supply chain problems that we have, really hard companies around the world, hard customers and users and et cetera. So what is Salsa? Salsa is an open framework that help you to understand and justify originality of every artifact on each development stage from intake or make source to build and release, right? And to achieve that. So basically you need to keep so called provenance as an example. At the right side of this slide you can see this provenance, what is it? It's metadata or full history about how an artifact was produced at each stage. The idea is pretty much simple, right? Keep along with all your artifacts, all your binaries, all your configurations, all your stuff that you're producing during your development lifecycle, from intaking third parties through development, through packaging, to delivering your products to the customer or to the world, keeping the information, the history, the origination information of all this, how, when and why and by whom this artifact was built. So this is what provenance is about. Basically the idea is simple implementation is maybe more hard, but anyway it's kind of not so big deal as well. It's open framework, you can easily find it by the link and basically achieving salsa level two level of maturity. It's not a big deal because that means that for source code you have your version controlled. Basically, I believe even for small companies you control your versions, right? So it's just you have these vcs systems and et cetera for build stuff, scripted build and build service exist and is in place. So basically you are not built manually, right? You have a build system, you have artifactory, Jenkins or whatever, all these tools in place and all this automated. And you have all these YAML configurations, you can check these configurations, everything is under control. So this is what's all about. And the last one is provenance, right? This metadata that you store, you keep with all your artifacts, it is available, right, for checking. Provenance is authenticated and service generated, basically generating automatically. You of course can and could automatic provenance creation using Salsa GitHub actions, for example, if you are using GitHub or easily integrate these tools to your existing CI CD tools. If you are not using GitHub, for example, if you use Jenkins, Travis CI or whatever, it's not a problem. You can integrate into these systems. That's another great tool, insertoid station tool. You can attest that and use cosine for generating and verifying signatures of that stuff. Again, this is kind of framework and more the idea that you can take and use and think about that again, this is idea is pretty trivial. But if you start to do that, there will be more trust to your artifacts, even by yourselves and by your partners, of course your customers or whatever. And again, that is all automatable. That's why I bring it up and would like to pay your attention to this stuff. It all could be integrated into your DevOps CI CD pipeline easily and that helps you to fit sac really easily to your DevOps practices. To have the full devsecops. And actually sometimes without really security team. That's basically pretty much it. I wanted to talk about today. I hope you learned something useful. Got an idea? Please do not hesitate to follow all the link and reference I share. That's all free. And please reach out to me in case if you have any questions. That was my pleasure folks. Please enjoy the rest of your day and take care.