---
title: "Kayra Otaner -- DevSecOps"
url: https://appsecpodcast.com/kayra-otaner-devsecops/
date: 2024-10-29
duration_seconds: 1966
season: 11
episode: 27
guests: ["Kayra Otaner"]
topics: ["DevSecOps and CI/CD"]
audio: https://www.buzzsprout.com/1730684/episodes/16006275-kayra-otaner-devsecops.mp3
video: https://www.youtube.com/watch?v=mcNu7sPUU5g
transcript: true
---

# Kayra Otaner -- DevSecOps

*October 29, 2024 · 33 min · Season 11, episode 27*

with [Kayra Otaner](https://appsecpodcast.com/guests/kayra-otaner/)

on [DevSecOps and CI/CD](https://appsecpodcast.com/topics/devsecops/)

[Audio](https://www.buzzsprout.com/1730684/episodes/16006275-kayra-otaner-devsecops.mp3) · [Video](https://www.youtube.com/watch?v=mcNu7sPUU5g)

## Show notes

Kayra Otaner joins the podcast today to discuss DevSecOps and answer the question, is it dead? Kayra is the Director of DevSecOps at Roche and is highly involved in the DevSecOps community. Kayra states that DevSecOps in its traditional form is “dead” and that each organization should approach its needs based on their size. Otaner introduces the concept of "security as code" and "policy as code" as more effective approaches, where security functions are codified rather than relying on traditional documentation and checklists. Finally, they discuss the emergence of Application Security Posture Management (ASPM) tools as the "SIM for AppSec," suggesting these tools, especially when enhanced with AI, could help manage the overwhelming number of security alerts and issues that currently plague development teams.

The Application Security Podcast is brought to you by [Security Journey](https://www.securityjourney.com/).

About Security Journey  
We provide diverse training content and easy-to-digest lessons to meet individual learner needs.  
→ [Learn more about Security Journey](https://www.securityjourney.com/)

Connect with Kayra Otaner:  
→ [Books by Yuval Noah Harari](https://www.ynharari.com/)  
→ [Roche](https://www.roche.com/)

Mentioned in this episode:  
→ [Books by Yuval Noah Harari](https://www.ynharari.com/)  
→ [Roche](https://www.roche.com/)  
→ [CISA Zero Trust Maturity Model](https://www.cisa.gov/zero-trust-maturity-model)  
→ [The Phoenix Project](https://itrevolution.com/product/the-phoenix-project/)  
→ [OWASP DefectDojo](https://owasp.org/www-project-defectdojo/)  
→ [OWASP Dependency-Track](https://dependencytrack.org/)  
→ [Phoenix Security](https://phoenix.security/)

Chapters:  
00:00 Meet Kayra Otaner: DevSecOps  
01:47 I like to be controversial about our discipline. And there was  
03:59 All right. Well, Kayra, I think we're going to dive right  
09:28 Right  
12:29 No, I agree with you there. I mean, there's definitely not  
16:17 Can you gimme an example of a problem in which security  
19:58 Makes sense. So what about zero trust  
23:12 Yeah, so lightning round are 3 questions that we typically ask  
25:34 Kero, what would be a key takeaway or a call to  
27:09 Yeah. And Defect Dojo is a commercial entity now. So I  
30:32 I'm going to disagree with you to some regard. I'm an

## Transcript

*5,311 words · assemblyai*

**0:00 Chris Romeo:** Kera O'Tanner is the Director of DevSecOps at Roche, where he leads the adoption of shift-left strategies and implements security and policy-as-code practices. Previously at ADP, FICO, and WPP, he served as a trusted CTO advisor, architected cyber defense solutions for the Turkish Navy deployed in NATO's Lock Shields 2017 and 2018 war games. He's an active member of DevOps and CoffeeOps meetups in New York City and a member of the Business and CS Advisory board for Middlesex County College in New Jersey. He's also delivered talks at numerous international DevSecOps conferences. Keira joins us to discuss if DevSecOps is dead, zero trust and DevSecOps intersection, security as code, and how all these things fit together.

**0:49 Kayra Otaner:** The Application Security Podcast is brought to you by Security Journey. We provide diverse training content and easy-to-digest lessons to meet individual learner needs. Learners report improving their knowledge as much as 85% on AppSec topics. Learn more at securityjourney.com.

**1:04 Chris Romeo:** Hey folks, welcome to another episode of the Application Security Podcast. This is Chris Romeo, CEO of Devichi, the threat modeling company. As always, joined by my good friend, Robert Herblot.

**1:27 Robert Hurlbut:** Hey, Robert. Hey, Chris. Yeah, Robert Hurlbut, Principal Application Security Architect and Threat Modeling Lead at Acquia. And as you mentioned, always glad to be here as well to talk about AppSec.

**1:38 Chris Romeo:** So we're going to get controversial this week. We usually, well, we always try to, I always try to get controversial, not like in a Howard Stern kind of way.

**1:45 Robert Hurlbut:** Hey, right.

**1:46 Chris Romeo:** But I like to be controversial about our discipline. And there was, as respect for as possible way. I was going to say in a respectful way, but as respectful as possible. So we're joined by Keyur Otaner, and Keyur, we always start with security origin story. And this is your first time visit to the podcast. So we would love to hear your journey into security. How did you get started? How'd you ultimately get to AppSec and DevSecOps?

**2:15 Kayra Otaner:** Yeah, it's just a long story. I'm not sure if you have enough time, but I I was started using Linux back in 1994, one of the first earliest adopters of Linux in my college. Since then, security was part of everything. You know, you remember those days, 3.0, Windows 3.0, 3.1, Windows 95. You always was in this camp that security is always a primary concern, or privacy is always the primary concern versus the folks that who likes to use the mouse, you know, like with double clicks. 3 buttons, you know, clicking through the UI. So security journey started back in 1994, and about since then I started, you know, working for companies that was regulated. Worked for FICO, handled a lot of credit cards. At one point in time, I remember we were touching or securing 50 million credit cards number, 50 million credit cards a day. And then started working for WPP. This was a SOX compliant company. Uh, media giant. Um, between my US journey, I went back to my original country, Turkey, where I'm from, and, um, set up my own company. So I have a lot of small and big, medium, uh, big and medium startups. They become the biggest companies in Turkey. Helped, uh, building their blue teams, um, SOC operations to a certain degree, uh, help architecting some defense solutions for the NATO countries. And then came back to States, worked for ADP as the director of DevSecOps. Now I'm the director of DevSecOps with Roche. So you can always say, you can say, you know, that I was a system admin at heart, was a DevOps guy, and then, you know, was DevOps plus security guy with the emergence of DevSecOps. Now I'm the DevSecOps guy.

**3:59 Robert Hurlbut:** All right. Well, Kayra, I think we're going to dive right into the controversy question, and that is, is DevSecOps dead?

**4:12 Kayra Otaner:** It's an anti-pattern. We are observing, and it's actually one of the ideas that I've discussed in my RSA talk last year, 2022 or 2023. We are implementing in a way that is not sustainable. So the DevSecOps, the way that we We defined DevSecOps as shifting responsibility of security to developers instead of shifting the developer know-how to the security people. So the easiest way was, hey, let's get these developers trained on the security, let's show them how to code the code in most OWASP Top 10 friendly way and reduce the SQL injections, all the issues.

**4:57 Chris Romeo:** Yeah.

**4:57 Kayra Otaner:** And it's not working. And it's not working because the developers have a tendency to ignore or forget the things that you teach them. And I have been giving this example for the last 5 years. You might remember that, you know, a lot of horror stories around like the developers put this table or make this change in the code and deploy that to production that killed the database, right?

**5:23 Chris Romeo:** Yeah.

**5:23 Kayra Otaner:** They killed the database because they forgot to write a query that there's an index or there's a WHERE statement. So they were querying these big tables with millions of rows being returned. So in QA and dev, you're perfectly fine. When you deploy to production, it kills the database. So the database knowledge is relatively simpler in terms of sophistication when you compare it to security know-how, right? The developer crowd was not even able to fully grab or understand the fundamentals of SQL querying or WHERE statements or indexes or table structures or how to write a left join or right join properly. So they keep making the same mistakes that's, you know, that was kind of prevented with the frameworks nowadays, but they keep making similar mistakes. In security, asking them to do security is always almost going to result in the same type of Horror stories.

**6:20 Chris Romeo:** So I'm somebody who recently has been thinking about DevSecOps a lot, and I do think it's dead. So let me, let me break down my perception and Kayra, I'd be curious to see if, if this tracks with you or if this, if you think I'm off base in some way. DevSecOps is not build pipelines. Build pipelines are here to stay. I don't see us until somebody comes up with a better idea where one AI bot create something and send it to another AI bot and they all work together to produce something we call software. But DevOps was, and ultimately DevSecOps is very much influenced or was the influencer for the build pipeline. But I think we can extract that from DevOps and DevSecOps now. And so when I think that, I think that we never really closed on DevSecOps. I think the ops part was always the forgotten piece that nobody actually ever did anything with. Everybody agreed this is the best possible thing that we could do it. And we read The Phoenix Project and we went, yes, the ops team needs to be involved in everything that's happening. I don't think anybody actually did it. I think it's, I think it's, I think it was a pipe dream and people just didn't make it a reality. Now, Kayra, is that your experience as well, or do you have a different— view of how this works.

**7:42 Kayra Otaner:** And not just ops, not just ops, but security. That's my observation as well. I can give you a couple of references that you might also like mention. You might also mention the Zero Trust Maturity Model or DoD's DevSecOps reference docs. They always talk about like having a separate distinct team to operate security. So when it comes to operation, you expect the developers have been going to acquire the knowledge to operate an infrastructure with 6 nines or 5 nines, right? That part is pipe dream. And also you expect the security is fully owned and executed by the developers. That's also another pipe dream. But if you take the DevSecOps at its core value of breaking up the silos and bringing everyone together, that's the dream that we can achieve, right? But if you shift everything towards the dev, that's the shift left, right? That is not scalable or sustainable because of ops issues that you mentioned, because of security issues that—

**8:32 Robert Hurlbut:** Yeah.

**8:33 Kayra Otaner:** you're observing because of the complication and sophistication of all the issues, as opposed to simple dev operation, which is kind of, you know, we are moving towards the AI territory. They can be automated to a certain degree, but so many security things and so many ops things cannot be really automated to the sophistication that a human or expert-level know-how can be uploaded to the developer's skillset or developer's brain.

**9:00 Chris Romeo:** Right. Now, in the DOD example, I would expect DOD, United States Department of Defense, to recommend that teams be separate and isolated, but they do it from more of a national security perspective. They're not normally very pro-information sharing amongst functional teams because it's a weakness.

**9:27 Robert Hurlbut:** Yeah.

**9:28 Chris Romeo:** Right? If everybody's talking to everybody, everybody knows, all of a sudden we start living in a top-secret world and everybody can't know everything, right? Because that's not how that works.

**9:37 Kayra Otaner:** I kindly disagree with what you just said. They understand the importance of security better than most common startups are. If you look at small startups that have less than 50 or 200 people in their team, they want to do everything with as small a budget as possible, right? They throw everything into a small 4-people team. and expect the security, ops, and dev to be 100% ready. Then that's not sustainable. Once they become enough, get enough funding, Series D, Series C, and then they become more bigger, they, the first thing that they do is separate security. Have that, you know, prevent that maker-checker problem. Have that segregation of duties executed. Guess what? DOD or big corporate, corporates like mega corps, like the ADPs and Roche that I work for, We do have this bandwidth or vision that we don't want to rely on a small team that does everything for us. The breaking up silos is all, we're all for it, but expecting everything to be executed by a simple same team is not just because of the OD, anyone that understands the importance of security, they have to do it this way.

**10:39 Chris Romeo:** Yeah, I just think the intersection of development and security, I mean, throw ops out of the way, we know that ops, just a lot of people, most people have missed on the ops connection there. Development and security, how far have we really come in the last 5 years as far as being able to impact developers with security? I certainly think that's still the best way forward. I think that's the only way we're successful in the long run is developers become security champions who can at least get us 50 or 75% of the way there. Because it doesn't matter where we go in the future, we're never going to have 500 security people and 500 developers. I mean, who knows, maybe AI will change the world greatly in ways I can't predict, but—

**11:27 Kayra Otaner:** There are a couple other notes that I can share with you. There is no one-size-fits-all. It's actually one-size-fits-none. There are small organizations, medium-sized organizations, large organizations, extra-large organizations, and there's defense, but there's this critical infrastructure. Right? There's 16 industries that are, that has special, that requires special attention, right? So you cannot apply the stuff that really works on DevOps with small team sizes or DevSecOps pattern to those big corporations. And this is very similar to like, you know, the rules of physics or air resistance changes when you're driving at 50 miles an hour versus like, you know, if you go beyond the, you know, a sound barrier, if you go around like a 6 max or like an 8, 5 max.

**12:10 Robert Hurlbut:** Yeah.

**12:10 Kayra Otaner:** the rules of physics changes. So you don't expect same type of wind resistance with the air friction and whatnot. Why are we expecting same type of rules to be applied to from smallest companies that are financially stable to the big corporations or mega corporations? That's not reasonable.

**12:29 Chris Romeo:** No, I agree with you there. I mean, there's definitely not one size fits all for anything. I've worked in the largest companies, And the smallest of startups. And, and it's a very different resourcing perspective as far as what we have to do there. But at the end of the day, I'm like, what even is DevSecOps? I'm declaring that it's dead, but would, like, it's, it's to your definition, Kayra, it was like, well, it's the, it's the development, security, and operations teams working closely together and breaking down silos.

**13:05 Robert Hurlbut:** Yeah.

**13:06 Chris Romeo:** Well, we've already achieved the silo breaking is, feels like it's gone between, I mean, it doesn't feel like there's a wall anymore between development and security. Maybe, maybe development's not executing on where our dream is as security people, but nothing happens overnight anywhere. So, we can't expect that somehow development was going to embrace security and all become junior or mid-level security engineers.

**13:32 Kayra Otaner:** Yeah.

**13:32 Chris Romeo:** in even 5 or 7 years' time. That's a 20, 30-year projection, more than likely.

**13:37 Kayra Otaner:** I mean, this is a good segue to my— one of my specialty areas. So, the original implementation of DevSecOps in even large corporations was like, ask devs to do more security. So, we are pivoting that with the security as code or policy as code. We are asking security folks to write more code in the form of security as code or policy as code, or sometimes I see like reference to compliance as code or audit as code, right? This wasn't there about 5 years ago, right? David, if you go back 10 years, the infrastructure as code wasn't there neither. You had simple Ansible scripts. Now it's becoming, you know, they become much more scalable with the Terraforms and other stuff, right? So we are seeing security to be convertible to code, or we are seeing some standardization across various formats that the teams are exchanging the security information or As an example, SBOM, right? Or justification labels like VEX files. So all of these advances are making security folks like ourselves, right, to become more developer. And in my opinion, that's right to left, not shifting left, but right moving towards left. That's proper DevSecOps for the large megacorp point of perspective. Does that make sense?

**14:49 Chris Romeo:** Yeah, yeah. So I mean, in that explanation though, Security as code, we don't really need DevSecOps anymore though. Like security as code, I feel like is here to stay. It's a pattern of creating repeatable processes in configuration files that can be, that can be presented across the entire, everything we build. We can apply things to everything that we build in an automated fashion.

**15:19 Kayra Otaner:** But if you remember very early, stages of DevOps innovation or DevOps pattern, right? We start realizing that ops teams can write CI/CD pipelines or can write Ansible scripts or some stuff that can make the life of developers easy and give it to them or collaborate with them. That is breaking up the silos and you codify certain functions, ops functions initially. Now we are seeing, we are telling that the security functions can also be codified. That itself, the codification is the key. If you are codifying certain things instead of publishing PDF files that sets the standards or compliances or checklists that someone needs to put pen and paper, like, you know, check those checkboxes, that's not real security. It's not scalable, but compliance and security needs more agility and security as code approach that DevSecOps can bring into the picture. is kind of the answer to that question.

**16:17 Chris Romeo:** Can you gimme an example of a problem in which security as code is the solution? I wanna make sure I'm tracking with, I've never really looked at it that closely, to be honest, perfectly honest, you know? So I'm just, I'm trying to wrap my brain around, okay, what are we, what's the problem that security as code is the solution for?

**16:37 Kayra Otaner:** Now we are going into my interview question territory, but I'm gonna give you the answer right over here. So everyone who's watching my, this podcast can get the answers from, the source. So in my opinion, this is my personal opinion, the way that I define doesn't have to be accepted by anyone. Security as code is implementing security to detect issues with very high false positive rates, right? With a lot of noise. It's primarily focused on detection. We do put like SAST scanning, SCA tools, SBOM creation with, I call it precision guesswork, right? We precisely guess what's going on over there. Policy as code is a pass or fail decision. It's easier to explain, so I'm gonna give you a Dockerfile example. So you have a Dockerfile, a plain text file, that has no user line. It's defaulting to root, right? So if you don't have a user line that says user is nobody, that's fail, right? You have a policy as code that can check for this type of pattern all the way in. I'm scanning, we have a part of that pipeline in the companies that I work for, I built these pipelines. that looks for all these policies. And we call this policy as code. And you can write these in Python, you can write this with, you know, Rego, OpenRego. You can write them with code, you know, I forgot the name, Cody. There's another pattern that you can write these codes. Essentially, they are the same. You can write with, you know, even Bash. So the policy as code is the way that you approach the problem. It's a pass or fail. You don't have to break the build, but that's, you know, but giving you a compliance state, and it's an internal standard check, or you might map them to external compliances. Security as Code is like giving you a lot of noise. Sometimes people say, oh, it's a step in our pipeline, we can put it into our CI/CD pipeline. Yeah, you should, but I rarely see people adopting those steps in their pipelines because it's creating a lot of noise, right? If you're in the DevSecOps, role for a governance body, you know, GRC function, like I am, you wanna capture all the noise, regardless of it's noise or not. That's a problem for the DevOps teams, but we wanna capture that in the security as code plus policy as code implementation. And again, this is my way of defining these things.

**18:55 Chris Romeo:** So, security as code, so you lumped in SAST and SCA and other tooling, So, you lump those in the security as code category?

**19:07 Kayra Otaner:** Uh, when you put them into pipeline, yes, uh, in the pipeline.

**19:14 Chris Romeo:** So, security as code is the codification, just to use the word code too many times, of the pipeline in a configuration file/script, which includes those other tools, those tools that we just expect magically work in the pipeline?

**19:31 Kayra Otaner:** It gives you a CVE or a CWE. Essentially, that's the output, right? The outcome is like you have a lot of CWEs, CVEs becoming visible to you with the security as code inside your pipeline, right? So, it's not a defensive coding technique that you need to implement in your Node.js application and put some security as code into your code. That's not my way of defining it. From the governance function point of view.

**19:57 Chris Romeo:** Okay, makes sense. So what about zero trust? How does zero trust fit into DevSecOps and security as code?

**20:09 Kayra Otaner:** Actually, it's a very relevant topic. You might have been following CISA and the Zero Trust Maturity Model 2.0. That was announced about a year ago, August '23, if I'm not mistaken. It talks about different maturity levels. And on top of 5 pillars, one of them is identity, the other one is network, devices, whatnot. And the pillar that we are focusing on is the application and workloads, right? That pillar has varying 3 different levels of maturity. An advanced level of maturity dictates or asks that in order for you to become Zero Trust compatible, an advanced maturity level, Use distinct and coordinated development, operation, and security teams. That's DevSecOps, right? Distinct and coordinated teams for each function. Distinct yet coordinated. I guess this is a very good and elegant way of putting for macro corps or mega corps or for DoD or zero trust companies that need to be zero trust. You want to have distinct but coordinated DevSecOps teams that has different functions, but tightly talking to each other, not just once a month meeting, once a week meeting, talking to each other all the time.

**21:31 Robert Hurlbut:** So how would, so we talked about security as code, we talked about zero trust, but do all those 3, DevSecOps and all the others, do they all interact well? Do they fit together well, or do you have to do some extra things to make them work?

**21:55 Kayra Otaner:** I mean, so not everyone, every company has to be zero trust, right?

**21:59 Robert Hurlbut:** Okay.

**22:00 Kayra Otaner:** So assume that you want to achieve some certain level of maturity in your zero trust journey, and it's a security journey, right? Assume that you have enough resources, number of people, budget, whatnot, then that distinct and coordinated team in the devs with the security as code and policy as code implemented one way or another, you will achieve good zero trust while getting good DevSecOps velocity, right?

**22:31 Robert Hurlbut:** Mm-hmm.

**22:31 Kayra Otaner:** But if you're in a small organization, no zero trust, You know, you just go all the way in with the pure shift left or start from the left. Okay.

**22:48 Chris Romeo:** Yeah, I think it makes sense how these things are all coming together here. And yeah, so let's move into the lightning round, Robert. I'm curious to hear Kayra's opinions here on a few of these questions. So with that, Robert, take away the Robert Hurlbut-sponsored lightning round. Okay.

**23:12 Robert Hurlbut:** Yeah, so lightning round are 3 questions that we typically ask, uh, especially folks who are joining us the first time. Uh, so the first one is, uh, what's your most controversial opinion on application security and why do you hold that view?

**23:23 Kayra Otaner:** Well, that's the— we just talked about that all like for the last 15 minutes. My controversial, which is I guess We are 95% aligning on that perspective. Shift-left is not for everyone. Shift-left is only for people that are, or companies that are at the smaller scale or service scale without compliance requirements. Shift-left can be implemented in that manner, a regular conventional manner, but it's an anti-pattern for bigger corporations.

**23:51 Chris Romeo:** Okay.

**23:56 Robert Hurlbut:** Next one is, if you could display a single message on a billboard at the RSA or Black Hat conference, what would it say?

**24:03 Kayra Otaner:** Layers, layer 8 is application. Layer 7 is applications, but layer 8 is also, I'm sorry, layer 8 is source code.

**24:17 Robert Hurlbut:** Okay, source code, okay.

**24:19 Kayra Otaner:** Layer 8 is source code.

**24:20 Robert Hurlbut:** Gotcha, okay. Very cool. And then last question is, what's your top book recommendation and why do you find it valuable?

**24:29 Kayra Otaner:** I started reading Hari Rhee's book, started reading from the Homo sapiens, but I guess the AI evolution and his last book, I bought this from Amazon only 2 weeks ago. Last one is, forgot, it starts with N, Nexus, I guess. That is last book about the AI and how it helps the civilization and whatnot. I guess that's my, uh, I'm, I'm gonna read it most likely within 3 months, uh, and I can provide some feedback. That's the book that I recommend to everyone because I read a lot of good reviews about that thing. And AI is actually what we are, we have been waiting for last, I don't know, 20 years, maybe 30 years. Because as you might have seen in the RSA conference that we are finally getting into the balance with the, the, the, you know, bad guys, you know, the attackers, right? defenders are getting enough ammunition and getting enough capability with the AIs that they're going to make this asymmetric warfare to bring that to parity. And that's my biggest hope.

**25:30 Chris Romeo:** Very cool.

**25:32 Robert Hurlbut:** Yeah.

**25:33 Chris Romeo:** Well, Kero, what would be a key takeaway or a call to action for our audience?

**25:38 Kayra Otaner:** So one thing that I mentioned to anyone that is on the AppSec space is, I'm coming from the NetSec, Network Situation Awareness camp, and I've deployed SIEMs, SOCs, intrusion detection systems for a lot of places. So in my opinion, ASPM, Application Security Posture Management tools, are the SIEM for AppSec, and it used to be called AppSOC, right? For a good reason. So I think by implementing AppSec for product security space or application space, you will close the loop on this OSI layers, right? That's why I gave you this layer 8 is source code. OSI layers define layer 1 through layer 7, start with the physical, goes all the way to application, but not source code level visibility is there. ASPM kind of brings that visibility with the AppSec tooling, of course. Once you have all layer 7 plus layer 8 coined together, you have full spectrum and full network situational awareness. I guess that's from security practitioners' perspective, that's the North Star. And AppSec guys, we should have, you know, ASPM. There are a lot of open source ones. I don't want to mention proprietary ones. DefectDojo is one, Quarky is another one. These are from well-funded, well-run, you know, well-developed tools ecosystems. Dependency Track is kind of another one you might also use. You know, go all the way in, get your AppSec results, SBOM stored in one location, get a grip on your AppSec status. Yeah.

**27:09 Chris Romeo:** Yeah. And Defect Dojo is a commercial entity now. So I mean, yes, they're an open source component. So, um, I'm very familiar with Phoenix Security and what Francesco is doing there. So I, but I agree with you 100%. Like I grew up in the days of SOCs and before we had SIEMs where we had to like use scripts to try to find intelligence from security devices. And I see ASPM as really just the SIEM for the AppSec world. And I think that's, we've been buried in so many, so much alert fatigue in AppSec with your SAST and your SCA and your DAST and, you know, the RASP and all of these things coming together. But it's, I don't know how, like, how do we dump 5,000 issues on a developer and like expect them to be successful? Like, hey, go be successful with—

**27:59 Kayra Otaner:** Yeah.

**27:59 Chris Romeo:** 5,000 tickets that'll take you the rest of your career to try to close unless you grab a script to close them.

**28:05 Kayra Otaner:** That's coordinated chaos. And we are shooting ourselves in our foot with this, this many, this noisy tooling and ASPM-like tools, very similar to SIEMs filtering through the noise and detecting those signatures are, I guess, there and ASPM can really achieve real meaningful results with the AI integration. I'm seeing early signs of it already coming in. And I hope that coordinated care is going to become less entropy and more precise within 2 years.

**28:37 Chris Romeo:** There's a conference talk to be had there, coordinated chaos.

**28:42 Kayra Otaner:** And you just stole my— actually, I may have used that in my RSA submission this year.

**28:47 Chris Romeo:** Aha.

**28:48 Robert Hurlbut:** Okay.

**28:48 Chris Romeo:** Yeah.

**28:49 Kayra Otaner:** I may have used that one. Yeah.

**28:51 Chris Romeo:** Coordinated chaos. I always invent new conference talks. It's just a thing I like to do is come up with, well, we had what, DevSecOps? Oh, I don't know if I was, yeah, DevSecOps is a dream.

**29:03 Kayra Otaner:** I was like, DevSecOps is precision guesswork.

**29:06 Chris Romeo:** Well, I like that one too. It's precision guesswork. That makes it sound better though. Then I'm, I don't know. I don't know what it is. Maybe I'm just getting sour in my old age or something. Maybe that's it. But I'm just not seeing, there's certain things I'm just not seeing anymore in DevSecOps. It just doesn't really make a lot of sense to me.

**29:22 Kayra Otaner:** I just, I don't, I guess everyone watching this podcast, including yourself, are mature enough to see that this story has repeated 5 times already throughout my professional life, right?

**29:32 Chris Romeo:** Yeah.

**29:32 Kayra Otaner:** We have seen evolutions have taken place, first on-prem, then first mainframe, then PCs, and then cloud computing. And then, you know, there are different iterations, but we are coming to the point that, you know, everything, with every iteration, we are getting more mature. And understanding that human nature plays a critical role in the security because security is always like, you know, you're the weakest point, right? So investing in training people is not scalable and it's not going to work because security— humans are the weakest link in security. That's what I've seen in the last 25 years in every cycle. Don't invest heavily on the human training or education, invest in the systems, codify things. And I'm going to use the same buzzword, security as code or policy as code manner nowadays, so that, you know, the AI tooling, which is coming very close, you know, happening sometime soon, help us in proper way.

**30:31 Chris Romeo:** I'm going to disagree with you to some regard. I'm an old school defense in depth person, right?

**30:40 Robert Hurlbut:** Right?

**30:40 Chris Romeo:** We have multiple layers of protections. Policy is code, security is code, that's a layer, but developer education is a layer, and guardrails and paved roads is another. Like, we gotta put, to have the best chance of securing the things that we build today, we have to embrace all the layers. Are all of them gonna pay off in the same way and have the same ROI?

**31:04 Robert Hurlbut:** No.

**31:05 Chris Romeo:** But it doesn't mean that I don't have a seatbelt and an airbag because an airbag is probably going to pay off more in a car crash. But for some reason, I still have a seatbelt too, because you know what, maybe the airbag fails or, or so multiple layers of defense are always what I'm going to prescribe. And I'm going to take as many layers as my budget can afford.

**31:25 Kayra Otaner:** Yeah. I mean, what, what, what we are adding right now is FSD, full self-driving, or or full supervised driving, right? With the airbags and the belts and the brakes, everything, but we now have the FSD because we can do it right now, right? I have a Tesla car. Most people have EVs nowadays. You know, it works, right? Defense in depth doesn't, you know, of course, you know, we have to have the brakes, we have to have the airbags for the worst of the worst-case scenarios, but Those extremes, we have more problems that are less extreme than extreme, most extreme problems, right? You have so many fender bender problems that can be prevented with FSD. That's the noise that we are trying to solve, right? That's the noise that we are trying to resolve with reducing the false positives coming at us. Yeah.

**32:21 Chris Romeo:** Well, Keren, thanks for taking the time to be with us here on the show, for sharing your perspectives on DevSecOps and zero trust, I finally have an idea what security as code is, so that's good. I try to learn something in every interview, and I learned— that was the primary thing I took away from this. So, we thank you for sharing your wisdom and your experiences, and we look forward to catching you at a conference soon.

**32:44 Kayra Otaner:** Thank you for having me.

**32:45 Chris Romeo:** Thank you.

---

Source: https://appsecpodcast.com/kayra-otaner-devsecops/