DevOps Topeaks

#25 - DevSecOps

• Omer & Meir • Season 1 • Episode 25

Share episode

Send us a text

This week we talked about yet another undiscussed (kidding) buzz word - "DevSecOps". What is it? Where did it come from? What falls under the category?

Things mentioned:

  • https://helix-editor.com/
  • https://httpd.apache.org/docs/2.4/programs/ab.html
  • https://github.com/kubernetes/autoscaler

Meir's blog: https://meirg.co.il
Omer's blog: https://omerxx.com
Telegram channel: https://t.me/espressops

Oh. And action. Yes, Leo already. Omer is just ready. I am now, I'm learning French. So ready is pre. Like bread. Bread? Pre. Pre. We. Okay. Hi everyone. And welcome to the 25th, the 25th. 25th episode of DevOps topics. And today, we will have Omer on the line. Thank you, Omer for coming. Very special. Yeah, no problem. It's all the time. No problem. You called me so I can. No problem. And today, we are going to talk about a very hot subject that we have no idea about this subject. And the topic subject thing is called DevSecOps. DevSecOps. And the Omer, I have a question for you. Are you ready? I'm not sure. I'm not sure. I lost your video now. Does that make sense? No, I'm still here. Okay, yeah, just go. Yeah, we have good connection. I trust technology. Me too. So I trust technology. Yeah. That is the first thing that comes up to your mind. When I say DevSecOps. Okay, DevSecOps. I wasn't prepared, you know? I mean, I'm prepared to talk about it for my life. Okay, let's talk about that. We, I think we talked about it in my life a million times. No, DevSecOps. Oh, okay. I think we talked about DevOps like a million times. We described the origins. We talked about how it all started. This guy, Patrick Dubois, mentioning it in a blog post somewhere around 2011, DevSecOps is a bit different. I couldn't find the actual origins, which would be interesting to hear from you or from the audience where it came. You know, the origin. But every major. This is the origin we are doing now. This is it. We're defining it now. We are the origin. That's good. That's nice approach. So I found it in every major company's website, Red Hat, AWS, IBM, Google, everyone has their own notion of what DevSecOps is. And the idea is basically, do you have a CISO in your company, Meg? I think it's me. Right. It's you. That's a perfect answer to what I wanted to ask. I feel like it's integrating a CISO into DevOps, it's giving DevOps yet another something to do. But let us just recall that DevOps wasn't meant to be a title of anyone. It's not supposed to be an engineer. It's an engineering culture. Right. So DevSecOps is just part of the culture. It's the idea of integrating security processes into DevOps as if it wasn't clear to begin with. Now we're actually saying that to mention that we need to integrate DevSecOps. So that's the first thing. It's kind of weird, because it's like taking this already buzzword and making it even more buzzy, let's say. That's the first thing. What's yours? I totally agree. I mean, it's just saying like, OK, this is a black microphone, which is very dark. This is like the exact same thing in my eyes saying DevOps and DevSecOps is like microphone. That's what you're saying. Yeah, exactly. Because it means that if you're doing DevOps, you probably have some security involved. Now maybe both of us are a way, way, way out of line. Maybe both of us don't have any idea what DevSecOps means. But from my perspective, DevOps must include security-based practices. Otherwise, what are you doing? OK. I agree. But let's go into the wisdom thing. What is it actually? So what security processes do you think are part of your day-to-day work? Where do you come in? You said I'm my own CISO, but let's say you had a CISO. Does that mean you no longer have the responsibility of managing security processes? Does that mean you only have the responsibility to manage very certain aspects of it? For example, a CICD process, maybe how Docker images are built? Or do you have an extensive responsibility to take care of the infrastructure? So let's start the code and let's say this. Maybe you can classify processes and then say, OK, this is sick. This is not or something like that. So I'll start. What about the companies maybe SSO? If you want to do a single sign-on to AWS account, do you consider it like that DevOps engineer must, I don't know, implement some DevSecOps process for the company in order to have an AWS single sign-on? Is it part of DevSecOps? Is it part of CISO? What is it part of? I would say it is part of your work if there's no CISO slash IT department in your company, definitely. However, I don't think it's part of DevSecOps because from what I could to understand, and even that's what I think. The security aspects of DevOps are not maintaining the company user directory access to certain systems or it's different, right? It's about managing processes, again, something that I mentioned slowly, slowly. So moving on, building a Docker image and scanning for vulnerabilities, is it part of DevSecOps? OK. Yes. What am I saying, yes, because that falls into this notion of shift left, right? Shift left is the idea of taking a certain aspect or a certain part of a process and moving it earlier in the chain of things that are happening. For example, if we talk about security as part of a CICD process, that means I'm taking the approach of security and putting it like higher up the chain in the beginning of the line. So shifting left the focus of security. Does that make sense? I got more. I got more. Sure, sure. I got more. Penetration testing. OK, trying to destroy an application, maybe we hire some external company, is it part of the DevSecOps doing pen testing, penetration testing to an application? Or maybe even before I continue, like you like it, the OASP, right, or the, how do you call it? The OASP deals with the web application security, yes, but what you've mentioned is exactly falling under another segment, which is the responsibility of compliance. And that's another thing. If you read about DevSecOps, DevSecOps as part of the list of things that needs to be included, one of them is being compliant. It doesn't mean you own the compliancy, it doesn't mean you start it, but if you need to be compliant, so if the application needs to be compliant or the infrastructure need to be compliant, that falls under DevSecOps. It doesn't mean that the DevOps engineer, again, there shouldn't be a DevOps engineer taking care of it. It just falls under the category. So if you're a company that's employing DevSecOps culture, part of the stack is being compliant. So if you're a CISO or your IT department says that you now need to be compliant with SOC or ISA, then it's your response, and you're, I don't know who it is, who's your VPR&D DevOps engineer and an ops engineer, someone's job is to make sure that you're compliant. And part of it, yes, it's penetrating testing. Sure. Okay. And the you maybe have a separation between scanning Docker images and code scanning, like, you know, scan for vulnerabilities in the code is different than scanning vulnerabilities in Docker images. Maybe it's even different than scanning vulnerabilities in packages, like, do you have a separation or is it all part of the DevSecOps? So I like your question. Why do I like it? Because we both come from the angle of ops more rather than the dev part, which we talked about in earlier episodes. And I think that scanning images, like Docker images, falls right under the ops part of the DevSecOps, which is mostly what I do. And for that reason, I'm not expecting the CISO or the IT manager or anyone coming to me and asking me, are you scanning your images? Sure. If you go through SOC2, they'll ask you and they'll make sure that you are scanning your Docker images. However, even before that, even before I'm trying to be compliant, that's, that's a standard, like, basic practice. If you're running Docker images in the cloud, surely in production, you must scan them for security vulnerabilities. Every major repo you'd use for hosting your images can probably scan. Most of them will probably use Claire, right? That's the most widely used open source scanner. So that's part of the work. Okay. So it's like, it's different from scanning the code, because you, you really focused on the scanning Docker images. But how about scanning filth parties like package Jason, maybe on local, whatever, or scanning the code, the actual code, you know, my JavaScript code, my Java code, whatever. Is that part of DevSecOps? That's, that's another good question. If it's part of DevSecOps, yes, whether it's part of ops job, that kind of falls in between, right? Pentration testing is literally scanning the application, understand or always stuff. It's literally understanding whether the application is vulnerable. Using container images is pretty much scanning the infrastructure, understanding where that's vulnerable. That falls under the category of ops, even if we're not employing DevSecOps and I'm the ops engineer, I should probably take care of it. It's under my responsibility. However, what you're saying here, kind of falls in between. So it's a good question. Is it part of DevSecOps? Sure. Is it part of my work as an ops engineer? Is it part of my work as a Dev engineer? I don't know. What do you think? It sounds hybrid, sounds like it has a DevOps engineer of a company. You probably need to provide the platform for the developers to allow them or enable them to scan their code, let's say, with sonocubals, nickel, any other code scanning a little bit. I think like to automate it, like so it can be part of the automation of the CICD pipelines. But again, the developers should be independent, right, like you should let them do anything on their own, they should create their own pipelines and then you only supposed to support them. So I do think it's in between. I have scanning and then scanning, I mean. I totally agree with you. But now let's speak about specifically about third party scanning, library scanning. Who should be the person in the company asking for it to happen? Sure, anyone can come up with it. Any developer can think about, I hope, any developer can think about that, any ops engineer can think about that. Who's responsible? Who do you think? You're asking the wrong way. Every time something happens, you need to ask yourself, who's to blame? Then you do the integral from that, okay? So who's to blame? If there is a vulnerability in a package, who's to blame the DevOps engineer or the developers, what do you think? That's the thing. I can give you the political answer, which is everyone and no one at the same time because it's the developer's responsibility to understand the library that is putting in and it's the ops engineer responsibility to be in charge of the CICD process and make sure that nothing funny is integrated into production because I'm the owner of production, I'm the owner of the environment. At least that's how we do things nowadays, right? I know other companies have the notion of usability on it and that includes the environment. So if a developer pushed something into production, it's his responsibility to fix. Be that a line of code or a new third party library. By the way, as for libraries, sure, you can scan them. I don't think I've never been a part of a company or a team that had the process of integrating a new library and if a new third party library, it mostly works by, let's go to GitHub does it have enough stars? Was it maintained recently? Is the commit recent? Let's go with that. Okay. And then that's it. Well, I mean, hopefully someone would scan it, but that's it. Nobody knows about it unless you see the diff in the merge request. That's basically it. Do you have a policy for that? Actually no, but I think that like, well, I work like we do a bit of a, it's a bit of a process, but I don't think it's because of security, but more of how it affects the application on the application side or the algorithm side, performance and stuff, but it's not focused on security. Of course, we do make sure that like, you know, a simple Google for checking vulnerabilities in, but not something like it's a, it's a nice to have. Okay. I don't think that it's something super mandatory. We do do, we do it, but, but I can say that we have a very, very organized process for every new third party, you know, at least not that I'm aware of. Maybe the developers do know something or maybe the compliance manager do have something, but I'm not aware of something that is, you know, extraordinarily. So if I'm trying to sum up what we're both saying is that it's a good notion. We should have it. We should all take care of security. It's not very clear who's in charge. Is that CISO IT? If they're even part of the company, is it the DevOps engineer, is it the ops engineer? Maybe none of this exists. It's just a team of developers. Do you know ops engineers? I've never heard of someone saying, I'm an ops engineer and that's it. I always heard like people are DevOps engineers and then I'm an infrastructure engineer. I'm a CI CD engineer, but that their hat, you know, the role is DevOps engineer. When I go online and I try to present myself and what I, I mean, I'm currently only on the side of development. I spend only on ops and when I do that, I try to present myself as an ops engineers, as an ops engineer, sorry, because I really believe that there is no such thing as a DevOps engineer. It's just this fusion and it should be a culture. It feels weird. Every time I say DevOps, I mean, you can probably go back in our videos and you'll see I'm doing that. Air quotes all the time. DevOps engineer because it wasn't meant to be a title of anyone. So I try to, I mean, my LinkedIn title says DevOps, but it should be an ops engineer because if you're doing ops, you're doing ops. If you're doing that, you're doing them. You're probably not doing both at the same time, unless there are very special cases. But still, maybe we call it DevOps because it's part of, you know, I like to think it's DevOps engineer. I'm not going to dive into the specifically DevOps, but because we are writing scripts, because we create maybe Python applications, go-long applications, you know, write in maybe scripting languages to do stuff, then this is why they added the dev to the ops, because we do dev, but not as part of the organization's products, you know, we do internal development. It's more like of a, in DevOps, you know. Was it our most of the tools that you write in Telenal? Right. We talked about the last episode, the dev part of DevOps. Yeah. So you already know, I totally agree with every word you said, but sure. So when the sick come into DevSecOps, I have an open list, if you want to hear about it and tell me what you think of what AWS consider it, if we think about the cultural aspect. It has like four pillars, right? It starts with communication. What do you think communication means when you start talking about the security aspect of DevSecOps? I think it's what we've just talked about that like people are not really aware what the security and who is in charge of what? So you need to communicate like, hi, guys, I added a new third party. And then everybody needs to be aware of, hey, there's a new package over here. Let's see how we handle it, you know, so I think that's like a public communication. Totally. So that's the essence of communication, which by the way, I think is one of the most important skills for any team anywhere on every part of the organization, regardless of what you're doing. I believe communication is everything, everything, anything and everything. So that's communication, you said it perfectly. Another part, another pillar is people. What do you think? Where do you think people come in DevSecOps? Oh, I'd say people, but people really I'd say roles maybe, like maybe people is like, who is in charge of what, but I'm not sure, again, it's just a guest, like maybe people like, okay, this person is in charge of this, this person is in charge of that, but I'm describing roles, not sure what people means as a pillar. So I tell you what I understand and remember, I might be completely butchering the idea, but what I understand is that we need to take people and kind of transform them, because people are used to notions and being kind of enclosed in their own bubble. So if there's a software engineer, I'm in charge of software, I'm writing lines of code. Sure, I don't want to have bugs and stuff, but that's pretty much it. That's where the responsibility ends. That's why DevSecOps was invented, by the way, because DevSecOps used to kind of end their line of work where code ends and that's it. They don't care about anything anymore. And people, I think, is the aspect or the notion rather of transforming people from the notion they have about their work and integrating it with a security aspect. So taking a software developer, when we mentioned security as part of their job, it's not only understanding bugs, it's figuring out how they write secure code. If they're interacting with a database, maybe they need to consider vulnerabilities, like SQL injection or other type of web application, vulnerabilities that needs to be taken into account. So that's what I think same goes for DevOps or Ops engineers. You need to consider how Ops or security comes into play. I'm not sure every Ops engineer in the world thinks that security is part of their job. Maybe because there's a system and they expect someone to lay down security tasks on them, and if it's not coming from above, then there is nothing to do. I think it should come from the surface. I need to scan Docker images. I need to make sure my CI-CD process is secure. I need to make sure nobody can hack the easy to instances on Amazon. I need to make sure that secrets are coming from a secure store. That's their answer. So that's communication and that's communication and now that's people. The third thing from the four is technology, which is kind of broad. Do you have an idea of what technology is? Electricity, yeah. Yeah, exactly. No, I like these. One's in zeros. Yeah, yeah, maybe picking the right technology to do the best thing for security, you know, security wise, but again, I guess. So I think if I understand correctly what you said, which is exactly the thing, we make technology decisions every day, week, month, right, with big stuff. You can, as an ops engineer, decide whether you work with HashiCorp Vault or SSM on AWS or just plain old secrets in Git store. And you make technology decisions. And those decisions need to have the aspect of security. You need to make technology decisions not only based on how fast they are, how quick they are to implement, how well you know them. You also need to make those decisions based on how secure they are or how they integrate with your security systems or your existing infrastructure. That's technology. And the last one is, I think, pretty easy, is a process, right, which is again, kind of everything. But do you have an idea what a process is? Can you guess what it is? Maybe implement security processes as part of your existing processes. Yeah. Yes, I mean, I think, I think the idea, what they wanted to say, we integrate security into everything, right? Into people, we try to change their mind. In the communication, we need to communicate everything we do, including security vulnerabilities or improvements, et cetera. Technology is making this technology decision based on that. When it comes to processes, we should probably take, let's try to map every process we have in the organization. Deployment, technology adoption, onboarding of new users, offboarding, of employees, et cetera, et cetera. We have a lot of processes going on. And then we need to take each of them and consider the security aspects of each. And employee living the company, they have our AWS keys or our keys to notion or are logging to, I don't know, off the zero, right? So I think that's the idea that it's integrating. Exactly. Every process. That's the time to tell. Oh, it's my time already. Let's go. Let's go. Let's tackling you. Just wondering, okay, I didn't have two questions. Like, when it comes to Git, okay, specifically Git, do you feel like you're the Git engineer of the company or do developers? Like, are they, do they know Git well and everything? Like, do they know what are the Git hooks? You're not touching security now, right? Is this a random? It's going to touch in a second in security, because Git is also part of security in my eyes. So I'm asking like general question, like, do you feel that you are the responsible person in the organization as the DevOps engineer that knows Git may be better, because you know it from different perspectives? Do you feel that? What's my favorite answer to every question you have? It depends. Of course it depends. You can say anything about the same. It's an answer for everything. So pretty much the same. When I started as an ops engineer, again, I was looking, I tried understanding Git to a deeper level than just committing, pushing, and I don't know, cherry picking. And I was looking for information with the engineers, with software engineers I was working with. His time progressed. Some engineers were expecting me to be the source of information. Git engineer to work with something correctly. Yeah, I'm the Git engineer, because I spoke to pretty recently a team leader in the company who was asking me how do you get merge stuff or what's the difference with rebase and stuff like that? And I'm still thinking about it today, whether it's my responsibility or not. So I feel like over time, I kind of took on the responsibility of knowing Git better and understanding it to a deeper level, so I could help someone who's asking. I don't know. I still think it's a very much a software engineering skill, like the basic skill you should have. So moving on to my entire question, that's what I'm interested in. Git, right, so when it comes to DevSecOps and Git, okay, if it's a developer, or not even a developer, maybe QA, it doesn't really matter, even a DevOps engineer, when you commit a SQLite to the repository, right, commit a SQLite or password or anything like that, do you consider like maybe avoiding doing that as part of DevSecOps? So for example, maybe if I told the developers, like every new developer that comes to the company, listen guys, nobody commits any secrets or any passwords, and if you do, there is a rebase, and then I teach them how to rebase and blah, blah, blah. Do you think, is this part of DevSecOps like teaching the culture of not committing stuff to Git? Of avoiding, you know, putting vulnerabilities in the code itself? Is it part of DevSecOps? Is it a question? Short answer? Yes, that's part of it. Surely part of DevSecOps, because that doesn't mean it's someone's job, it just means that's part of good practices. If we employ DevSecOps, we shouldn't commit secrets to Git, or shouldn't store them, and yeah, everything you said. However, if I won't be the one who's kind of standing in the gate and making sure that it runs smoothly and nothing secretive is inserted, then I'll end up with a huge pool of secrets, which then, as an ops engineer, I need to make sure those are removed. And with Git, as time progresses, Git saved the entire history. If you just commit a line you deleted, that doesn't mean that line doesn't exist anymore. It doesn't exist in production or word that's integrated, but if someone scans the repo in history, he can find the sensitive information. So you kind of force yourself into a very, very much more complex process of removing stuff from history, which is something that Git doesn't like, and you need to kind of drill down the history and kind of pick stuff that were inserted, they're injected by mistake and take them out. It's not nice. So you could say that it's not my responsibilities as developers. If I won't be the one taking responsibility over it, then I'm suffering later on. So, like, everything it depends, but I'll see that. So DevSecOps includes maybe not doing, not acting, I'm not trying to think how to say it. Like, not committing secrets, not doing stuff that can add vulnerabilities to an existing application or a new application or whatever. That's also part of it. That's exactly part of the process pillar. If we have processes, one of the processes in an engineering company is the process of reviewing code. Sure, there are processes on how you commit stuff, and let's say you buy mistake every one of us, I mean, surely you and I have committed sensitive information to a Git repo. Part of the process is being able to, or reviewing a merge request or a pull request, and sipping with the engineer, two engineers, team leader, whoever that may be, and reviewing the code. So, hopefully, we have a checklist of what we are going to do, whether that code is efficient, readable, functional, etc, etc. One of the things should be security. Is there sensitive information? Is it leading to sensitive information? And is it vulnerable? So, I think that's where this comes in. Another question. This time, it's not just Git, because there's also a Docker, you know. So, I'd say Git, you know, and Docker, you know. Okay, so every, okay. You know, sometimes developers can't get a repository, or like if you're a new DevOps engineer in a company, and then you see a lot of new repositories, because you're new. So, you can read the Git, you know, don't Git, you know, just for people who are listening. So, and then you read that file. And suddenly, in that Git, you know, I see that they didn't add, didn't add, the.estlicks, which means any file that is usually hidden, because files that usually start with a. Usually I'll hidden, okay. And then, of course, there's an exception, all those, the ES3 and the Git, you can always even start with a., but you can also, you know, do use the exclamation mark, and then you will be able to avoid ignoring, ignore files, and I'll see files and whatever. But who is in charge? Okay, putting it under the umbrella of DevSecOps. Who is in charge as part of this whole DevSecOps process of writing the correct Git, you know, maybe Docker, you know, or any other, you know, as part of this DevSecOps, you know, process or culture. Like, who's in job? DevOps, developers, ops engineers, developers. So I don't have a perfect answer. What I can answer is that, if you are employing DevSecOps, we talked about the poor pillars. Again, one of them is processed. If you are employing them, then I believe it should start from the top. So if this comes in from an architect or the architect of the company or the VPR&D, they should be in charge of employing a process of integrating security into everywhere. One of the places is this, like, integrating security into this process and understanding whether something funny is going on. So, again, I think we can pretty much answer it throughout every question you'll ask about security and where it comes in. Under who's responsibility, part of the process is defining responsibilities, by the way, when you go through SOC or RESO, there's a list of responsibilities of who should take or what. If there's a DevOps engineer, they should be in charge of scanning the containers. If you need to understand whether periodic, we talked about, what was it, for good. Anyway, if there's a periodic security check, whether virtual or physical, that's part of the CISO's responsibility, or the VPR&D, the VPR&D is the one signing the document at the end of the day. So part of it is to making sure there's a policy of who's responsible for what I believe we talked about it earlier, things that have to do with the code, there should be a put request or a merge request process on how to do stuff. It's not about blaming someone later, it's about just integrating the right process to minimize the occasions of security issues coming up. I mean, I know it's general question. I'm no more than gonna go about the old habits. Let's make it personal. Yeah. This one's nothing about your habits. So you encountered a new Git repository in your organization, or again, as I said, maybe you're a DevOps engineer, a new role. So do you have those maybe, I'd say habits or rituals? I'd call it the ritual. Okay. This is a new Git repository in my organization. Are you doing like, because this is what I do usually, when I say a new Git repository, I'm like, okay, let's check the Git, you know. Let's check the Docker, you know, if it exists, hopefully it does. Hopefully it does, you know. So do you also have those rituals of, you know, encountering a new animal in the wild and then trying to do your ritual on it? Unfortunately, no, because the way we work is slightly different, we work with a lot of lambda functions and I don't think that's the right thing to do, but it that enforces a lot of repos because mostly new functions are part of the new repo of their own and that kind of blows up. So what we do try to do is work with templates. It doesn't have to be a Git clone of the template. I think GitHub and GitLab have the option of using a repo as a template. So when you start a new repo, you just don't just reinvent the wheel. You go and use that as a template and that hopefully comes with a Docker ignore and a Git ignore and the way we write a readme file and a skeleton maybe of certain types of languages. So that's what we do. Hopefully I won't encounter, you know, a bad repo in the wild because we have that. So that's another process. Okay, so you're acting like you're saying I prevent it. You know, we already had this topic on it. I'm not gonna remember on which episode but we were like preventive or after the fact. Yeah. So I'm talking like maybe when you're coming to a company that still doesn't have a process like when we were consultants, both of us. You use, you know, you went to a customer and then you saw the GitLab postos and you were like, wait guys, you got tickets over here. You got dot n files that are committed. You got a Git ignore that doesn't include all the things that can possibly, maybe even not even for security. Maybe if some of the artifacts are zip files, then why don't you add asterisk.zip to your Git ignore? Why are you? So I'm trying to understand you as a personal question. Do you have any habits when you encounter and you get repository or you're like, dude, I'm with templates. I'm preventing everything from the beginning. Yeah, I actually have two answers. One, I'm trying to be very preventive in the sense of first of all, yes, creating the template and employing every best practice I can find. I will research what are the best practices for a secure Git repo. But having that said, I do have a tool that scans reports like you said in the wild and lets me know when something wrong happens. It mostly is used to understand configurations of the Git server. So we're working in GitLab. So I want to know if someone disable the enforcement of dual merge request reviews, right? I want to know about it. If someone disable the image scanning, I want to know about it. If someone disable the, what was it? There's a rule that prevents authors of commits within a merge request to be able to approve the merge request, which is kind of obvious. You don't want to approve your own code. It enforces a review by someone. So there are all kind of rules and checks that we try to periodically scan over across all of the repos once a day, once an hour. I don't remember and get notifications in alerts when something pops up. So that's kind of the counterpart of that. OK, so before we move on to the coronal, do you have any other topic that you want to discuss about the DevSecOps? I can tell you that I read about lots of approaches. Not a lot. It was like three, four, five approaches, which one of them was the ever-growing shift left thing, like being preventive, going up the chain, starting from the beginning. The other is shift right. I just learned that that's actually a thing. And that's focusing on what happens in production. I mean, after you deploy it, there's also like managing that's part of the lifecycle until the version goes down or goes out of production. There needs to be, you need to do stuff. It's not just a periodic penetration testing. Maybe you can run continuously continuous testing. Maybe you're running what they used to call it, chaos engineering. Maybe you're running stuff to make sure that the infrastructure isn't vulnerable to some kind of attacks or some kind of issues. When you take chaos engineering, I always think about Netflix is cool. Monkey, something, monkey, yes. Chaos monkey, yeah. I like it. They wrote a book about it. It's amazing. Never, sometimes. As a DevOps engineer, just to have fun with my developers, my developers, it's like a hobby. So I like to do stuff. You know, okay, today database, this is a build. What you do. You know, it's great. It's a great app. Okay, what I wanna say is I never actually had the pleasure of working in an environment where I can delete a database and see what happens. But I do think that you need to think about it. I mean, do know what chaos engineering is and maybe employ that as part of your thinking process. Because I like to think about it. What happens tomorrow with that Postgres database is gone. What happens if everything is just evaporating of a database? So I like to survive the element. But not in production, in development. You know, sometimes because development, you know, you can always take it down. That's the whole point of development. Not even staging because staging is for QA or whatever, but development, I like to do stuff in it. Okay, let's do something. You know, and then I get crazy. Yeah, totally. So just to sum up the answer to your question, those are the main two. There are a lot of other obvious ones. Promote security awareness, all kinds of stuff like that, which you can both think of. But I like the idea of shift left and shift right. Like, thinking about the start of the process, think about the end of the process. Not just we see why we work on something. So that's something I like. And I kind of, that's my takeaway. Let's keep it at the time. I didn't know that DevSecOps session, you know, the topic episode or whatever. I think you're trying to teach us to dance, you know, like shift left and shift right. But I think exactly. Okay, so are you ready for the corner? For the corner? I think I am. I think I am. Yes. Okay, so let's move to the corner and effects. Pochtop, corner of the week. Okay, corner of the week, yes. Okay, oh man. So I need you to tell me what experience or anything new that you've done learned acquired or anything technological or not technological as you've experienced this week. Okay, do you know being like that? I think so. V, V, yeah sounds fun. Okay, you know, you know, new of him, you know, new of him. That's also your love. Yes. Okay, new of him kind of builds on top of him. And it was a fork of him. And now it's the main branch, but new of him kind of took it to another level, starting to work with an actual language, which is Lua and integrating cool plugins based on that. So you now have a little bit of more shazam and visuals. And you can enjoy stuff like a modern ID. There is, however, a new ID, which is called Helix. And Helix is kind of what new of him gets to do with a lot of plugins, new of him, sorry. Helix tries to be doing that from the get go. It's like by default has a lot of plugins to help you with, I think, a debugger and LSPs and code awareness and stuff like object tree, et cetera, et cetera. It's pretty cool. I haven't tried it thoroughly to recommend or not recommend, but it's cool. So I think people should be aware of it. And obviously the idea is having something within the terminal, so it doesn't consume as many resources as other full blown ideas like VS code or PyCharm, et cetera. So Helix is my thing. What did you learn? What did you think in the description below or maybe up? I'm not sure. I experienced the Kubernetes horizontal pod autoscaler. So I delivered the meetup a few days ago. And as part of it, I showed how it's fun to work with the Kubernetes horizontal pod autoscaler, where you would just define resources for pods and then you deploy Kubernetes metric server. Following that, you create the horizontal pod autoscaler object and voila, use AB, you know, I like to use AB, the Apache's tool to send tons of requests to overload the system through some stress test and see the autoscating go up and down, you know, and it was great. So metrics, Kubernetes metric server, AB, and everything, I'll put a link to this get repository that I've created. It was very much fun. I really enjoyed it. And that's it. That's my part. All right, cool. Anything else? I don't think so. Okay. All right. So I guess just to mention again, just to mention again, we do, we have a Facebook page. If you want to ask something, yeah, it's really, it's there. Nothing's happening. I don't even think we posted it last week, but it's still there. If you want to contact us, just go there, ask a question, post anything. It's there. DevOps topics on Facebook here, I've said it. Mate, I think we need to open threads, threads user now. We have a new social network, maybe it's time. We will. That's it. Okay, so bye for now. Thanks, everyone. And see you next week. Bye, bye. Yeah, bye.