Kayra Otaner -- DevSecOps

0:00Chris RomeoKera 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:49Kayra OtanerThe 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:04Chris RomeoHey 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:27Robert HurlbutHey, 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:38Chris RomeoSo 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:45Robert HurlbutHey, right.

1:46Chris RomeoBut 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:15Kayra OtanerYeah, 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:59Robert HurlbutAll right. Well, Kayra, I think we're going to dive right into the controversy question, and that is, is DevSecOps dead?

4:12Kayra OtanerIt'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:57Chris RomeoYeah.

4:57Kayra OtanerAnd 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:23Chris RomeoYeah.

5:23Kayra OtanerThey 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:20Chris RomeoSo 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:42Kayra OtanerAnd 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:32Robert HurlbutYeah.

8:33Kayra Otaneryou'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:00Chris RomeoRight. 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:27Robert HurlbutYeah.

9:28Chris RomeoRight? 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:37Kayra OtanerI 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:39Chris RomeoYeah, 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:27Kayra OtanerThere 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:10Robert HurlbutYeah.

12:10Kayra Otanerthe 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:29Chris RomeoNo, 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:05Robert HurlbutYeah.

13:06Chris RomeoWell, 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:32Kayra OtanerYeah.

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

13:37Kayra OtanerI 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:49Chris RomeoYeah, 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:19Kayra OtanerBut 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:17Chris RomeoCan 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:37Kayra OtanerNow 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:55Chris RomeoSo, security as code, so you lumped in SAST and SCA and other tooling, So, you lump those in the security as code category?

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

19:14Chris RomeoSo, 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:31Kayra OtanerIt 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:57Chris RomeoOkay, makes sense. So what about zero trust? How does zero trust fit into DevSecOps and security as code?

20:09Kayra OtanerActually, 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:31Robert HurlbutSo 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:55Kayra OtanerI mean, so not everyone, every company has to be zero trust, right?

21:59Robert HurlbutOkay.

22:00Kayra OtanerSo 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:31Robert HurlbutMm-hmm.

22:31Kayra OtanerBut 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:48Chris RomeoYeah, 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:12Robert HurlbutYeah, 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:23Kayra OtanerWell, 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:51Chris RomeoOkay.

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

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

24:17Robert HurlbutOkay, source code, okay.

24:19Kayra OtanerLayer 8 is source code.

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

24:29Kayra OtanerI 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:30Chris RomeoVery cool.

25:32Robert HurlbutYeah.

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

25:38Kayra OtanerSo 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:09Chris RomeoYeah. 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:59Kayra OtanerYeah.

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

28:05Kayra OtanerThat'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:37Chris RomeoThere's a conference talk to be had there, coordinated chaos.

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

28:47Chris RomeoAha.

28:48Robert HurlbutOkay.

28:48Chris RomeoYeah.

28:49Kayra OtanerI may have used that one. Yeah.

28:51Chris RomeoCoordinated 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:03Kayra OtanerI was like, DevSecOps is precision guesswork.

29:06Chris RomeoWell, 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:22Kayra OtanerI 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:32Chris RomeoYeah.

29:32Kayra OtanerWe 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:31Chris RomeoI'm going to disagree with you to some regard. I'm an old school defense in depth person, right?

30:40Robert HurlbutRight?

30:40Chris RomeoWe 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:04Robert HurlbutNo.

31:05Chris RomeoBut 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:25Kayra OtanerYeah. 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:21Chris RomeoWell, 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:44Kayra OtanerThank you for having me.

32:45Chris RomeoThank you.