Shift Left. Shift Right. Shift Everywhere. EP1

Hey everyone, it's Alan Shimmel for Techstrong, and welcome to the first episode in a series we're doing that we call Schiff. Left Shift, right Shift Everywhere. I am really happy to be here.

I'm really happy to have these two guests I'm gonna introduce you to in a moment. You know, we're doing this series with our good friends at Adobe, and I know everyone out here has heard of Adobe, and many of you use Adobe products, but I don't know how many of you know how influential Adobe has been in the world of security over the years. When you, when people are trusting you with, with the, their files and their work, like millions around the world do with Adobe, they don't have a choice but to take security seriously.

And as we were talking with my guest offhand, off camera, you know, a lot of security innovation has come out of Adobe. Um, Adobe of course, is all about you, the technical people out there who are working in all of their products for graphics and documents and applications and everything else. And they have for a long time.

This whole series is gonna be focusing on sort of what's Adobe's view of security, about what's some of the sort frontiers, some of the, you know, areas of security that we, we wanna shine a light on. And, and specifically, as I said right in the title shift, left Shift, right Shift everywhere. Where do we put our focus on security?

Look, I've got two great folks from Adobe to introduce you to who are gonna be talking about this with me. Let me introduce them to you now. First I want to introduce you to Pelli Yuli.

I, I hope I got it right. I've got, I'm doing the best I can on names, but Pella's name is actually not that hard. Pelli is the lead security strategist at Adobe, and we're thrilled to have him on Pelli.

Welcome. Welcome to our podcast series here. Share with our audience a maybe a little bit about your journey.

Um, sure. So I've been in the security industry for 25 years. Um, I started out working for a company called anonymizer, which was sort of a commercial version of tour way back when.

Mm-hmm. Uh, I worked Insecurity consulting for a while with had Stake and Symantec, and I've been at Adobe for 17 years now, working in all sorts of areas of security. And, uh, when we brought, uh, Florian into the team, I decided to go and focus, uh, mostly on shift right type projects.

So I'll be representing the shift right aspect of it. So you're the right hand. Yes.

I hope it's still right on your, this is my right hand. I sometimes it mirrors. I know, but that's funny.

You know, at stake of course is legendary, right? Chris w Ball and, and the folks there, they went to semantics. So it sounds like you were involved in in all of that, you know, in the, in I've also been the security business 25, 30 years, legendary, legendary folks there.

It's still doing great things. Um, but thank you for joining us. Sure.

Next, let me introduce you to, uh, Florian nut Netting. No noting, I know you gotta curl your tongue in, in New York, we just don't curl it so well. But Florian nerding, Florian pronounce it correctly.

Tell a little bit about yourself. Help me rescue me, Difficult name my name's, uh, Florian nerding, or if you want to use a German ation because I'm originally from Germany and it's Floridian, which is even more difficult. But let me also talk a little bit about, about my background.

I started my professional career in, uh, 2000 and and 10 at a small startup, which built, um, network firewall de devices with a focus on being very, very user friendly so that anyone without networking or security ex expertise could actually set some up and have a secure net network for their, their office or their, their home. Even after a couple years working as a software engineer there, I joined at, at Adobe, and I've been with Adobe by now for 11 years. And, and, um, most of the, well, a bit more than half of of the time i, I spend in software engineering.

I, and it's still what I, I'm at heart. I'm a software engineer. I want to make the lives of, of developers better and really focus on pragmatic security solutions.

Roundabout six years, I, ago I joined the security org, started working to together with, with Palace, and I'm taking care of all things shift left. And so the cutoff point is basically when software gets deployed to the cloud or otherwise released to our customers. So in, in my scope is there's a lot of stuff from security training, security, awareness, code analyzers, and various aspects around secure by, by design and especially memory safety.

Safety. Excellent. So you're the left hand?

Yes. Got the left and the right. Okay.

I feel like the Pope, um, anyway, He's home from the hospital, so that's good. Anyway, um, let, let us, let us talk a little bit about history. com in 20 November of 2013, published March of 2014.

A big reason that I personally felt compelled to do this was because I thought that DevOps offered us the best hope of, of getting security right, of, of correcting a lot of wrongs, right? I I, I grew up, or I, or my career in security, probably much like you, Pellis was sh on the right side, right? AF post-deployment, I helped found a company, intrusion prevention network, access control, vulnerability management, you know, all the traditional network security stuff.

And the problem was we were, we were always the caboose on the engine, right? The end of the train, the engine got pulled by the developer or, or someone else, right? It was too late.

By the time we got involved, it was too late often to fix a lot of the wrongs that were there. And I always felt if we move further up the food chain further left, if you will, we would be able to fix these things. And what a perfect opportunity DevOps was, right?

Ops and dev working together, let's get security in there and we're going to move security to the left. And you know, the, at the time the notion was, and I don't know if you believe it, I'll ask you both, that it was a fraction of the cost to fix a vulnerability or a defect far left than it was to try to fix it in product production in the right hand, right? So it was cheaper, it was more efficient, it was, it was just everything was better doing it to the left.

And why start just left of deployment? Let's push it all the way left. Now, like both of you, we, we have friends who are developers, but the average security person said those developers, they don't care about security, they just wanna push out code, right?

They get paid to about how many lines of code they publish. But an interesting thing I learned when I got into this DevOps thing, a lot of the developers, and not only the developers, all the people on that left side really felt that the security people were like an anchor that was dragging them down. They were slowing us, we were slowing them down.

We were the people who say, no, no, no, nope. Go back, go back, go back. No.

And I found it incredibly difficult to bring together what I used to call the, the, the cybersecurity, or we didn't even call it cyber back then, but the security tribe with the DevOps community, it was sort of oil and water. I was trying to make chocolate and peanut butter. Pelli, you've been around if you were at at stake.

You've been around a while. I know. Yeah.

What, give us your take on that. What do you, you know, was, was it an impossible mission to begin with? Uh, I I don't think it's an impossible vision.

I mean, part of, even as a shift, right person, right? Like my job isn't just to find as many bugs as I can. My, I'm a feedback loop into, into Florian, right?

So, you know, we go and we try to look at patterns of, in within the vulnerabilities and say like, okay, are the developers having this consistent class of problems of having this consistent class of problems? You know, what can, you know, Florian and I coordinate on? And what can, uh, Florian help build to address that class of problems?

Like how can we shift the company to using a framework that's maybe a little bit, um, more secure by default so they don't have to think about security as much. Uh, maybe it's a pipeline problem. Maybe, you know, it's they're, they're having trouble keeping their amis up to date in, in the cloud.

So, uh, it's, I I found that developers tend to want to do security. Well, they, they, some, a lot of times they do find it sort of an interesting topic, but they're, they're just constrained by the realities of, of their situation, right? They, they have so much time and, um, to get things done.

So, uh, from my perspective, you know, I'm not just looking to find as many bugs as I can to get as many points on the board as I can. You know, everything's a feedback loop. Even if you're doing red teaming, the, the goal of a red team isn't to go Nina or n we got in the goal of the red team is to then talk to the blue team and say, look, this is how we got in this, this is where you have gaps.

Um, if you wanna catch this the next time we do this, here's how you can improve. And so there's always a feedback mechanism in, in from shift, right? To, to make the shift left team, uh, more knowledgeable and enable them to make better plans, to make things just smoother for the developers overall.

Absolutely. com, Florian did all this DevSecOps, to tell you the truth. Give us your, you know, what, what's been your experience at Adobe primarily?

'cause that's where you've been all these years, but is what I describe, was it true then? Is it true now? What, what's changed?

What's gotten better? So there are multiple perspectives on, on that. Soly DevOps, the, the ideas is fantastic.

We have a group of people who really focus on, on the engineering aspects of building working software and operations people who then run it in production and take care of all, all the problems that happening in productions there. We have a feedback loop too. And if we now add security to to, to that mix, both sides need to, to do some of the work.

But the challenge with shifting too far left is we security people should not move all security work to the en engineers operate as of systems because they are not experts. We are the experts. So we need to make it as simple as possible for them to find these issues.

And there are many different approaches of shifting left. For example, you might shift left and say, well, let's do threat modeling at design time, because obviously it's cheaper to change the design that hasn't been implemented yet. Then while you have a architectural complete, um, system on, on stage ready to be deployed to production now, and architecture change is very hard.

It's, it's too, too late. So shifting left in that sense, very Im important, giving all kinds of feedback in an IDE on, on the other hand, well, now you need to balance different aspects. Do you want to send all the findings to, to the developers only the sets that you care most about?

What is this the set, what, what security aspects really matter? And with my background as a software ENG engineer, I, I wanted to always help other software engineers make pragmatic security decisions and Italy reduce security decisions. So the recent trend in shifting left is secure by design solutions that's, for example, started for cross scripting issues, um, with libraries such as React, where it's really hard to accidentally have, um, injection vulnerabilities because the framework by design prevents it.

And that is a very, very powerful concept that I want to see much more. Yeah, the, the, the secure by design, that whole concept of secure by design does not get enough light, right? I mean we, we all, for instance, Pelli, I'm sure on the right side of things, right?

Uh, zero trust networks, zero. The, the idea of zero charge security, right? Everybody kind of wraps their head around that talks about it.

It's, it's very, you know, very, uh, everyone, you know, buys into it, so to speak, the secure by design. I think people shake their head, but they don't necessarily drink the Kool-Aid, if you will, right? In that.

'cause at the end of the day, they're not quite sure what secure by design means, right? Yes, of course we want to design secure software and we want to try to put in frameworks that take out your buffer overflow SQL injection, you the OO top 20 or whatever, right? That hasn't changed in 17 years, but, you know, but actually implementing that is hard.

It's hard. And without, again, some ground rules, we, let's not let out state secrets and get us all in trouble. But how does Adobe do secure by design?

Yeah. Let me talk a little bit about memory safety in, in this context because it, uh, showcases the fundamental challenges that we have have to deal with many of Adobe's products, like any company that that is more than 10 years old, probably has lots of CNC plus plus code. You know, operating systems are written and c and mostly c maybe some in CC plus plus desktop apps.

See foundational libraries are all CNC plus plus desktop apps themselves, c and c plus plus. Look at any network d device at code running on other than the apps on on your mobile phone, whether iOS or Android, it doesn't matter. The foundations is all C at c plus plus it's all memory unsafe.

And unfortunately we have learned that humans are not capable of reliably writing memory safe codes just too hard. So we need a, a system so solution, and that is memory safe programming languages where a smaller group of of people is just focused on, on designing a system where it is very, very hard to have accidents like, like that. If you use Java, Python, well these are not systems programming languages.

You don't deal with memory safety issues. If you need to write highly performant code, well then you have rust or may maybe swift. Uh, the two most common choice there are certainly more than these two programming languages.

But if you now look at, um, the ecosystem where you have memory safety issues, it's c and c plus plus. You can't just re widen an entire application in a memory safe programming language. There's no business case to ever make that happen.

Even if we had a way to automatically transform, uh, tens of millions lines of code base into two rust wouldn't be interesting because the teams that maintains the c plus plus code base couldn't maintain the rust code code base. They wouldn't understand the structure if we used AI to transform it, if that would be possible. So we need a much, much smarter a approach to memory safety.

And the first step is, again, feedback loops. We need to identify which parts of, of, um, the system are most vulnerable to this kind of vulnerability and does this vulnerability matter at, at all? And that is where the shift dry testing comes in.

And I'll hand it over in a moment to palace to speak about fuzzing and what we do there, and once we've identified these spot that are safety critical will recognize a recurring pattern that, especially areas that do, um, pausing and decoding of file formats are risky. And it doesn't matter if it's an image file format, an audio and, and, and video or a complex document or even an archive, it doesn't really matter. That is the key functionality that we need to protect because an adversary is that sends you a file via email phishing spear phishing, which is very targeted phishing.

And with one click, you open the attachment and then open it with an application, and then the adversary achieves remote code execution. That is really the thing we want to, so figuring out which code is executed during this one click attack that is most, most important and it's file pausing, decoding, and maybe a little bit of running logic, then you can take different mitigations strategies instead of rewriting everything in a memory safe programming language or maybe rewrite one safety critical component in a memory safe programming language. Palace.

Can you talk a bit about fa Yeah, sure. So, so this is one of the areas where like you, the goal isn't necessarily always just to find as many bucks as you can. It's to do things strategically.

And this is where shift left and shift, right? Collaborate. So yeah, when we're trying to decide what to fuzz, we could do like just generic fuzzing and try to go after the entire application all at once.

Um, but to do a more strategic approach, you would look at your adversary intelligence, right? Like in, in the wild what file format types are attackers currently using to go and exploit things? You can look at bug bounties and you know, the people that you have in your, your bug bounty community who are contributing crashing bugs and looking at the techniques that they're using because they're often also emulating what they are seeing, uh, in the adversary intel community.

And then you can go work with the product teams and go, okay, who are the teams that actually are responsible for this code? We can go and you send a specific team to there. We can work to set up fuzzing around that specific section of code and it can actually make the developer experience a little, uh, more predictable.

'cause you're, you're directly working with the team, you're working with one team at a time or two, maybe two or three teams at a time, uh, to do this type of work. They understand what, they understand the bugs, they're not context switching. Um, like if you're just fuzzing the overall application, you're hitting different teams all the time and they're contact switching versus, you know, working with a team directly where they're like, okay, we're gonna focus on this problem for, for this quarter and we'll, we'll work with you.

We'll set up the fers we'll, we'll give you insights. And then, uh, they can start to see the patterns in the bugs. And if they see the patterns in the bugs, they can say like, okay, well you, you can quite rank the fuzz.

We, we know this paradigm that exists in the code, so we're just gonna go tackle that overall and then we'll come back to the fuzz once we've, we've addressed that. So, uh, you know, with with Schiff Wright, you know, I'm always looking for ways not only just to, to find the bugs, but also ways, uh, to do it effectively and ways to empower the teams to move faster. You know, I remember the first time I was exposed to fuzzing, so I think it was black hat around 2006, maybe, something like that.

And, and what a, what a fantastic development that was for what the time, I don't even know if we called it AppSec ps I don't know if you remember, but did we call it AppSec then? No, not really. It was still, I guess vulnerability management.

I don't know. But I mean, what a, you know, the whole idea of fuzzing the code and looking for, you know, the, the zero days before the bad guys found him, if you will, was, was just, you know, what a concept like, duh, why didn't I think of that? Right?

And I wouldn't be working here today. But, um, it, it, it, it really did help us a lot and it helped the developers mix code, right? Not in real time, but much earlier in, in, in the, uh, in the process.

But, you know, I I also, I feel almost like duty bound to say we have made a lot of pro progress on memory overflows and, and, you know, memory vulnerabilities in, in our code at Adobe as well as, you know, all applications we're, we're better at finding those kinds of, of, uh, of defects of vulnerabilities now than we were 10 or 12 years ago. We, we, we have, and we also have new, you know, you mentioned, yes, the world's full of Brownfield, not greenfields, unfortunately, we have a lot of legacy code written in c and c plus and even C Sharp, but you know, we're seeing this at the Linux Foundation now, right? Lioness, lioness says we should be using rust.

Yeah, there's, there's definitely been a shift, and you've seen it across the industry that there has been progress, right? Like Microsoft's done a lot of work to introduce secure compiler flags. Yeah, that can help secure code at scale.

Um, Microsoft themselves have been playing with rust in, uh, in their code and they've been putting rest into the kernel. They've written a, a couple blogs about that. So things are getting better, but, um, at, at the same time, it's always a race, right?

So, you know, you're, you're always, they're always gonna find one more way or one more tactic. So it, it's always gonna be a bit of a progression, You know, it's good. I'm Sure it's finding in, you know, security is always constrained by the EE economies of building software and selling it.

So if you can't make money with it, well, even if it's perfectly secure and turning something off isn't usually more secure than running it. So we need to find an acceptable risk threshold, and for example, for our products, aggregate and, and reader, the addition of sandboxing to really isolate the memory, unsafe parts. And yes, we have active content and, and, and there too from the rest of this system allowed us, even before we had secure by design solutions like memory safe programming languages for systems use to reduce zero days and vulnerabilities in, in, in this area by large in degree.

So there are many, many different techniques. And, and the key thing to always figure out is what is the best way, the most cost efficient way to mitigate risks at scale? And as security professionals, we always have a pretty large toolbox available, and we need to help the software engineers understand what are the options and tell them about the different pros and, and and cons, both short term and, and long, long term.

A sandbox doesn't fundamentally remove the vulnerabilities and libraries that it protects. So we still have to, to fix any B bug we might find, whereas in a memory safe programming language, you have eliminated or reasonably eliminated a class of, of vulnerabilities. Yes, the rust you can use unsafe, but oh, then you better know what you're doing.

Yeah. And we're, we're sort of, uh, you talk about the industry changing, we're, uh, at a place where, you know, like when I first started, like finding a bug was super cool kind of thing, right? And now, uh, you know, and in a large enough company, you, you have, you have tons of bugs, right?

So like RS a coming up and there'll be a ton of vendors on the floor who are gonna be marketing, application security, posture management tools. Sure. Which are, you know, taking into account that you've got vulnerability feeds from all sorts of places.

You've got your internal pen tests, external pen test, bug bounties, dast, sas, Kev list, um, cloud security, posture management tools, et cetera, right? So you have vulnerability. You, you now have a wealth of vulnerability information available to you.

And, uh, part of working together with Shift left and Shift Dry is being able to look at that data and look at that information, say, how can developers most effectively spend their time to, to knock down as many vulnerabilities, uh, with as little effort as possible? Is it updating their baseline images? Is it, as Florian mentioned earlier, switching language to like react or rust?

Is there some sort of tool in the pipeline that we can build that makes, you know, keeping these things up to date more, uh, easier, uh, for the developers? Um, you know, managing third party libraries, you know, since right now we're at, like, almost at the other end of the spectrum where it's, we, we have a wealth of information. Now the question is, is how did, how do we use that information effectively?

Well, we're almost a half hour in and we haven't mentioned ai. It's time. You know, is AI the answer to that question, fellas?

Uh, AI definitely helps. Like AI is, is another tool in the toolbox, right? Uh, so, you know, you can use on the shift right side, there, there are places to use it.

And I'll let Ian talk about, uh, places in shift left, um, in the shift right side, like, because you have all these different tools, you'll have the same bug finding for multiple tools. And the a common, uh, AI function is document similarity search. So you can do, you can do deduplication, make sure that you're not double filing bugs against teams.

Uh, there are tools, uh, to make reproduce, uh, the reproduction of tool, uh, the reproduction of a vulnerability, uh, easier. So they can take a bug report and translate it into a nuclei template, which, uh, utilize an open source tool for, uh, doing scanning. Yes, that, that helps the development team in terms of reproducibility, uh, when they get a bug report.

So there's definitely places where, where it can help. And we've seen, uh, places where it helps and also places where it expands, you know, the attack surface that I have to monitor as well, flying up to, yeah, Expanding the attack surface is a good, good keyword. We are living in a world where more and more code will be authored, or at least co authored by AI systems.

And these large language models, which writes this code for us, have been trained on publicly available source code, which of course has been written by humans and has sometimes a lot of security issues. So you might find that AI generated code is not substantially better and maybe not substantially worse either than human written code. But since much more code will be generated than humans can produce in the same amount of time, we should probably think about, uh, addressing these concerns at the root cause.

So can we get into the space where, um, AI generate code for us to directly influence how the code is generated and take care of security recommendations at code generation time? That is as far left as we can, can go in, in, in the process. Um, at least for, for code, we can could also use AI to auto generate code fixes.

So if you understand a, a pattern well enough have AI after it was somehow detected, have AI rewrite the code and so that it's, um, vulnerability free, for example, from using string conation to create SQL statements to parameterized queries. And is especially Im important when queries need to be dynamically con constructed because in that's the edge case that humans often get, get one. We are also running other AI experiments, for example, on our block.

You can, can find a post about how we think of AI for use and, and threat modeling. That is an, an experiments that, that we are still con continuing to, to this day, to, to see can we recommend something where humans truly excel at with AI use to scale it across the entire company. Because, oh, economics, again, you can't threat model every tiny feature by a security specialist, but AI could, is it good enough?

And the answer is still, still open, but let's, let's see how, how this space e evolves. I don't think it's Good enough today, but it's getting better every day. Certainly.

And an interest thing we hear from security companies and developers is that today anyway, AI might be better at fixing bugs than it is writing code. So in other words, if you give a code that a human wrote, it could find and fix vulnerabilities, bugs, whatever you want to call it, and it does a better job than that. And then if you just ask it to write code for an application, then it, of course, a human or someone else has, you know, something else has to look at that code.

Um, but certainly we're not at the point where, where I think we can trust it to just write the code for us. And, and, and security is, is, is at the top of that list. Very much so.

Um, but you know, you mentioned something before about third party components, and this has really been a bane of shift left and shift right of shift everywhere. 'cause we have to be in the repos. I mean, today software is assembled on an assembly line, like cars are, I assume it's the same at Adobe, you're not a, right.

Most of that code inside of these applications represents components that come, they're open source perhaps, or they, you know, they come from repos, container repos or, or or whatever. And, and a lot of the security incidents that we read about or hear about are the result of third party vulnerabilities that made their way into code, not from the developer actually writing that code at the company, but from the third party component that was assembled into that code. This the software supply chain, this whole issue of SBOs software biller materials, right?

And that's a left and right issue because you know what, when you're assembling the code, integrating it prior to deploying, yes, you wanna make sure your SBO is, is up to speed. But that SBO has to almost be a dynamic document that, you know, as things change, it changes. And then pelli you on the right side of the house have to be able to reference that SBO to say, Hey, does this thing need an update?

Or is is a component here out of, out of, uh, you know, they found a vulnerability, we need to upgrade that component. Are you already starting to rely on SBOs to help fix or to help secure the software supply chain? Yes.

We, we do. That is one of the projects i, I lead, so, okay. Yeah.

And the basic idea is first you need to figure out where do is your visibility into the software composition limited, especially with cloud native applications, things that are developed in modern programming languages, any one of these Python, Java, ruby, JavaScript doesn't really matter. Usually has a good package manager. So it's relatively easy to introspect a GIT repository or a repository for the packages that, um, software depends on and figures that out even at deployment time.

Uh, cloud native security tooling can figure that out too. But there are gaps in older systems, especially CNC plus plus, again, just like memory safety is a, a problem there. The software composition is hard to determine automatically.

So we are working on, uh, on improving the ability ability, especially in these areas, to understand which dependencies to have our, uh, CNC plus plus based products, how do they relate to internally and to external components. And that of course, this visibility then enables us to, to have a more standardized approach to vulnerability management. And Palace mentioned earlier things such as the catalyst that a CSARs list, obviously known exported vulnerabilities, things that have been exported in the world, so we can prioritize the remediation of these issues and a whole lot more palace.

Yeah, and this is also a place where, you know, secure coding often gets talked about separately from just standard coding practices. And this is like an area too where, uh, you know, teams that have good development practices, they have the ability to do automated, uh, testing in their environments to confirm, confirm patches, uh, the work that they invest into that actually benefits security. Uh, it's a mutual win for both teams because the more, uh, testing they have that's automated and can confirm something and, and get you closer to a continuous deployment model, the easier it is for them to test these third party libraries.

Like one of the things that allowed developers, uh, have a challenge with, with testing these things is that occasionally there's, you know, a breaking change where you have to go and re-architecture code to, to deal with the new version, and they're always scared of that. And the longer that goes on, the higher the probability of that occurs. And so, uh, a lot of times, you know, when we're partnering with developers, we'll look for opportunities where the thing that they want is also something that we want.

And you know, so if we see them like, Hey, we wanna do initiative to improve testing, just normal testing, like unit testing within the organization, you know, we'll go and we'll back that and say, yeah, the security team believes that would be a good investment as well. So there's opportunities to look for, uh, partnering with, with organizations on that. And then from a shift right perspective, yeah, we have to keep track of all the feeds and what CBEs and, um, which ones are relevant.

You know, are they on the KEB list, making 'em a higher priority, uh, those types of things. So it is definitely something that we would monitor on the shift ride side. Great.

Guys, I've got one more topic area I want to jump in on and that actually brings us full circle back to the beginning. I said the name of our episode here is shift left Shift, right Shift everywhere. It's not enough to have one hand shifting, right?

And one hand shifting left. Those are two hands, they act independently and they're not necessarily coordinated, right? Video directors say, don't stick your hands out too far.

You go out of camera, so I gotta keep 'em here, but so your hands are not necessarily coordinated. The idea behind Shift everywhere is coordination left and right working together, right? Not in.

Absolutely. Yeah. Talk to me about how Adobe, other than having you both on the show with me, how Adobe is, is putting left and right together to truly shift everywhere.

Uh, sure. I I can start that one. Um, so one of the things you have to keep in mind too is we talk about shift left and shift, right?

And that's important to the security team, but when you're working with the product team, they, they just know the security org, right? So, you know, the reason why we wanna collaborate and work together and, and come up, you know, make sure that we're coming up with like unified solutions and looking for patterns and looking for higher ROI activities forum 'em is they wanna hear from a security team from a single with a single voice, right? They, they just need to know what they need to get done, um, and what needs to, to happen, uh, to get there.

And so, you know, with Florian and I, we we're in constant communication with each other every day, every day of the week, um, about some topic or another where they're, we're trying to collaborate so that when we go to development teams, there is a unified voice and I can say like, Hey, these group of bugs don't deal with them individually. It'd be better for you to do this thing. And Florian can help you.

Florian and his team can help guide you through that. And that makes, you know, just a better relationship between the security team and, and the development teams to, to know that we're not just coming up with work for them to, you know, busy work for them to do to, you know, prove we can find bugs, but that we're trying to actively work with them to, uh, get the most security from, from the limited time that they have. Um, and, and Florian, do you have anything you wanna add to that?

Yeah, um, we have so many different tools and as p said, speaking with one voice is, is most important. So telling the engineering and operations teams what exactly is the most efficient and effective way to reduce their security burden, that is really important. This problem feel might feel simple if you only deal with one product, but at Adobe I'm dealing with many different products.

So I need to rely on multiple teams that help both s and me send this message and amplify it at scale to many, many en en engineering teams that use different tech stacks, have different products, have different business cases, are facing different kinds of threats. So in really identifying what are the key things from a risk perspective to protect our crown jewells, and this might vary by, by product certainly is very I important. And then PE and I work closely together to figure out what are these risks.

We work with our security partners to amplify our message, and we work with the security partners to pull in the specialized functions of our security organization to affect positive change. And the part of that is certainly also evangelizing for security to create awareness because, um, not all business leaders might be aware of the security threats a product is, is facing. So really having a holistic perspective is super important.

And there is a model that I use, how, how to think about the, kind of the maturity of, um, the security that that we have. And I found it on, uh, Colin Green's block. The basic, I I am, when you classically think about shifting left, you start with the development process.

So design, write code, build test, deep deploy and and, and so on, and then left this at the beginning of that process. But instead you can, can have a different model that Colin Green called see the six buckets of security risk and the right most one where I start is exploited. That is the thing we want to avoid.

Then we have the bucket of unfound. And most risks probably stay there. If you now add investments, you can shift things further left to found externally, for example, via bug bounty program.

Further left, found internally, but manually manual testing, pen testing thing that rat teaming, oh, you can decide if that's external or internal, doesn't matter too much. Even further left, found automatically with an automated code analyzer solution and even further left to prevent it. And then ask your safety question, what is your maturity?

Where do you prevent risks? Where have you only capabilities to find them automatically or man manually? And that is much more, more expensive.

Then the economical question is not, can I do this at this time and moment, find a security issue, but how can I address the root causes of issues instead of only fixing symptoms? So it's a whole different way of thinking about a vulnerability management program and using all the tools you have at hand to make it better. That was excellent.

Thank you Florian. Guys, as I Promised you when we started, I was gonna try to keep this under 45 minutes. We're, we're hitting right up against it.

I feel like we've barely scratched the surface though we have a lot more to go over and I look forward to continuing our discussions in, in subsequent episodes of, of this series. But I think we've laid a great, a great foundation here and, and defined a lot of these things. And what's nice is sometimes we talk about this in such an abstract way because we don't have a real live company who's actually living and breathing this every day.

Adobe is living and breathing this every day. And, and that brings a, a, a reality show, if you will, aspect of things where, hey, this is, this is what we're doing and this is what works for us. So thank you both for coming on.

Thank you to Adobe for participating in this series. Thank you for watching this. I hope you found it interesting.

Um, if you're watching a summary of this, click through, go watch the full, the full 45 minute version. It's great. Until next time, this is Allen Shimmel for Techstrong.

Thanks for what, what being with us today.