DevSecOps is Dead, Long Live DevSecOps

all right thanks everybody for coming I'm going to go ahead and get us started uh my name is kly price I am CEO and co-founder of zadex security we a sponsor of bides Buffalo and I'm excited to be a sponsor of bsides Buffalo even though it meant a flight from Seattle uh because I love small Regional conferences our focus at zatic is small and medium businesses and helping them be secure by Design because so much of the security industry is leaving small and medium businesses behind and not meeting their needs and what better place to come and actually talk to people and understand the realities they're facing than at Regional conferences so I was just recently at uh

nolon in New Orleans uh I'm going to Richmond Virginia after this and so after the talk today uh if anyone's like any of this ated or I want to talk to you about some of the challenges we have at my company I would love to talk about them my co-founder Zack Glick is a buffalo native he's actually speaking in track 2 right now and I jokingly refer to him as The Unofficial mayor of Buffalo because he is constantly trying to convince me and anyone else who will listen that we should all relocate to Buffalo it's going to be great cost of living is good climate change is apparently going to really benefit y'all and uh so I figured we had to come and

and be here today what I'm going to talk about uh oh I've been in security like 20 years uh did a bunch of incident response you can find me on LinkedIn if you if you really care about all the things I've done in the past and why I should be here um but this was a really hard talk to prepare for uh when I first wrote it because I was very uh depressed uh I was very sad vulnerabilities are still getting popped every day log for J was was uh you know a couple years ago I had to work that incident well my team had to work that incident it was we are now 10 years

after heart bleed and what have we learned it is rinse and repeat attackers are getting in through weak passwords through shared passwords through credential stuffing they don't need oday to compromise a company they can fish you uh they can fish your Marketing in turn and because companies haven't done a good job of of zero trust implementation because it's hard and it's expensive and we'll eventually get to it a lot of them have flat networks still a lot of them are still running with uh no employee access controls so you have access to everything uh within the company and there's no logging so nobody knows the developer in San Francisco has been logging in from Russia at 2: in the morning and

downloading 2 terab of customer data so it's feeling like we're not making progress and honestly I would just like to go off the grid and raise baby goats but that is not a helpful conference talk and also baby grows grow up into adult grats and they're kind of creepy so uh so let's actually talk about how we can make security better and we're going to talk about Dev SEC Ops but it applies Beyond devops as well that if security were just a technical problem we would have automated it already it would not continue to be a problem security is a human problem and humans are complicated and humans are terrible at assessing risk in General on

the one hand they're sort of okay at threat modeling just naturally I live in a high crime neighborhood and I have really valuable stuff I should block my door I should have a good lock maybe I want bars on my windows maybe I want a dog I live in the country down a 2m dirtt Road I'm 10 mi from my nearest neighbor and I have Ikea furniture and no electronics who cares if I lock the door and and so people think that way about their belongings to some degree um women walk to their car in in the parking lot with keys threaded through their fingers because they're threat modeling their wrist but when it comes to cyber risk

yes I will click that link it looks completely legitimate and I want to see the dancing hamsters that sounds great um and so there have been studies that indicate after somebody's uh credit card got compromised about 10 years ago and they had to deal with all the pain in the butt calls to the bank and arguing about fraud that they would get a a lot more aware of their security for a few months and then it would Trail off again and now banks are so good at detecting fraud and preventing it from going through and notifying you uh that doesn't even happen anymore and so that's great technology is preventing uh the bad things from happening and we've got

better detection but it changes people's awareness of their risk and this happens all the time in technology and among Engineers is anyone really going to attack that that seems really implausible you end up debating theoretical risk versus real risk with your engineering teams because they want to go ship new features they don't want to do this boring hygiene maintenance stuff and so developers make poor choices just like our neighbors do and uh you know I know this other developer is using the LI PNG Library I'm going to use it too it's clearly already been approved by whoever approves what libraries R use well why are you implementing two different versions of libpng in your application aren't you linking them why

don't you have a centralized store for this this you realize next li PNG vulnerability you have to patch both of them in your code base oh you you're not patching your codebase for open source vulnerabilities because that's theoretical risk and the volume is too high and you need to ship features and and so all these tradeoffs get made um with some pretty questionable outcomes so why is devs op so popular if Developers aren't really great at assessing risk well it's the promise of less security Interruption we're going to enable the developers we're going to shift left and enable the developers they're smart they'll make the right decisions if we give them the information how many developers do you

know who actually understand what CVSs means it's just like Blinky lights and colors it's like this is red that's bad why is it red I disagree with you that should be read but I can't explain why I disagree red you know and and so we're throwing security tools at them um without actually giving them that Baseline knowledge and and the idea that we can shift left and make it the engineers issue to go resolve um is really popular among Executives who see security as a roadblock security is a is a friction point for Innovation so we're going to enable able the developers to own their risk but do the developers understand their risk we haven't asked that

question effectively in most organizations that are racing towards Dev SEC Ops and a lot of Dev SEC Ops programs are really just we're going to throw some tools in the dev pipeline it's not really a program it's just sast dast software component analysis we're good right um so the engineering team is now deputized to own security risk without understanding security risk um and we can lower the size and the budget for security headcount and the security organization which looks really good on the p&l statements so here's how devs Ops gets done wrong we've got all these tools in the dev pipeline that we expect developers to go look at security dashboards and then understand them and there's a dozen or more

different tools they have to look at if you're using GitHub you might have GitHub Advanced security which has uh secret Le like a detection for secrets that are in code and insecurely restored it has dependabot it'll help you identify what uh dependencies need patching but you've also got um probably something like sneak or fossa because dependabot is great for finding the vulnerability dependencies not good for your legal licensing risk and so you might still need a secondary solution in that pipeline because you're not just dealing with technical risk you've got your SAS tooling and your Das tooling some of those tools have overlap maybe you're in an environment that's running sonar Cube detectify lace work and

they're all finding different vulnerabilities and you expect the developers to go look at each of these tool dashboards and in some cases manually cut Jura tickets or as your devops or GitHub tickets to go fix the thing and all of these tools report by cve so let's imagine for a minute that you've got an open source library that released a new version that fixed 25 cves those tools will list 25 findings in your codebase instead of saying hey developer go update free type and you will resolve 25 vulnerabilities it's going to issue 25 findings that look like noise and is not helping the developer do the job but also so we've talked about tool noise uh

they don't look at those dashboards as you get better at finding vulnerabilities you're going to make your engineering teams even more frustrated because you're digging up more issues for them to go fix I have had a vice president of engineering ask me after 6 months of my team fixing all the broken tools in the dev Pipeline and we started issuing tickets in waves because we knew we would overwhelm them in complete Earnest sincerity he asked when security would be done filing tickets well um when the product goes out of support it's not even when it ends development it's when it goes out of support that we will stop filing tickets because then we can tell

customers it's unsupported code we don't patch it anymore but we will never be done filing tickets and so we are constantly showing up with more work for our engineering teams um we expect the engineers to be experts at everything including these security issues that they don't necessarily understand but then engineering isn't staffed to maintain all this open source that they use I give an entire talk on open source risk and most Engineers walk out of it angry at me that I have told them you are now an IT admin that has to worry about patching your code base every time any open source releases an update and none of them open but there's no Patch

Tuesday for open source they just release fixes whenever they have a fix available and you have to monitor your sneak or your fossa or your whatever ever your tool is to go update that and and what's crazy is those tools are an improvement over what the industry had in 2014 in 2014 when heart bleed hit I was working in incident response at blackberry and I subscribed to every open-source mailing list for free type lib PNG web kit I got hundreds of emails I I was scraping siunia to look for every single open- Source issue that would affect our products it was all manual so so I'm not trying to complain about software component analysis tools

it is better than what we used to have but there's still a ways to go and improving the developer experience and the developer workflow and honestly even the security teams security teams workflow so if engineering isn't staffed to maintain excuse me if they're not staffed to maintain all the open source they're using um and and to be clear they're using open source because it accelerates development but it doesn't accelerate maintenance um we also have a problem that security isn't staffed to provide adequate coverage in depth so the the engineering team comes to the security team and says hey we need your help doing a threat model or a design review of this new product that

we're going to release in um 6 months and the security team says 6 months I have another team that showed up 3 days ago and said they're releasing next week I have to scramble and throw myself on that and we'll we'll get to you sometime before you release and so we're not showing up when they need us because we're also under staffed so this comes down to blame fear and avoidance engineering teams avoid working with security because we're not helpful we're late uh and when we do show up we tell them no and we're frustrated with engineering teams because they show up late they're not doing what we think they should do because they don't understand what we

think they should do and it creates this tension and hostility between security and Engineering teams which gets back to this is why devs Ops is popular we're going to put control in the hands of the developers because developers run the company um because they're creating what generates revenue and there is nothing to secure without the developers so we all have jobs because of developers we are a cost center um and how do we get to a point where we're enabling the business versus slowing it down and we look at every problem as an absolute frequently we have a shortage of experienced security talent in this industry and we will throw engineers at every problem even when maybe a program

manager is the better solution we will hire all senior people instead of hiring Junior entry level training people up because security is too high risk and we have a limited security budget and we don't have time to train people and so we need a security a senior security engineer so go configure octa no you don't you don't need a senior security engineer for that you don't need a senior security engineer to triage your hacker one or your bug crowd bug Bounty you do need senior security Engineers but you also need other skill sets and other uh capabilities within your team um you know we can eliminate toil through a lot of our great security engineering and

tooling and and an entry-level person is who's going to end up picking up the little bits of toil we still haven't automated and there will always be toil so we've we've got to really diversify our toolkit and that's not just the technical tools but our human resources as well in these teams Engineers don't get excited about driving stakeholder alignment they're not really great at writing executive Communications about risk because they get into the details of this is a buffer overflow with a CVSs of 9.8 that results in remote code execution and the vice president who has to sign off on that risk understands none of that it the the line from uh the first Avengers movie where Iron Man is talking

to Captain America and Captain America says it appears to run on some sort of electricity that is the executive reaction to this is a CVSs 9.8 remote code execution vulnerability due to buff or Overflow what the executive needs to hear is a malformed font in email if the customer is using HTML rendering will compromise memory on the device and the only workaround is to view your email in plain text well that's an unacceptable user experience we can't allow that to ship and now the executive is motivated to fix it

that's going to come from your program managers your customer focused technical writers who can take the technical information from the engineer and communicate it in a way the audience can understand sometimes that audience is your developers and not just the executives so we're back to baby goats because I'm still very depressed and frustrated about the state of the security industry um okay now we'll try something new let's try something new as we've talked about security Engineers aren't good at everything when you are solving a simple problem maybe you can go solve it alone but security is rarely a simple problem and you need to build your party you may need a barbarian a Bard and a

rogue for this particular thing and uh maybe you you know you're barred as your Communications expert and your Rogue is the person who's really good at thinking offensive security and maybe you're Barbarian is the person doing your um automation development work where it's like we're going to hammer this code together and reduce toil and it's going to be great like think about how you build your teams and your organizations um and what you bring to that table in terms of diversity to get the job done because as we talked about security is a human problem it's not just a technical problem and so bringing these diverse views into your security organizations um really helps you build

a better program and get better uh get better outcomes I am a cleric Bard I uh all about helping people and making things better and the communication and the storytelling um but a lot of Engineers view all of that as soft skills and I have friends how hard can it be it's actually very very hard uh and and it there is a tradecraft to being great at not just this sort of soft communication but shaping The Narrative not just giving people data but telling them what the data means and what they should think about it and this is what our engineering Partners need from us is opinionated advice about this is why this is risky and how we should

fix it and then a dialogue where they can share Maybe why they disagree yes yes we do use the log for J library but we don't use the vulnerable component well a security team should have caught that already but they didn't and that's okay because we can have the conversation about okay we don't use the vulnerable component how are we going to message that to customers because customers are running vul scanning and they're freaking out that they think we're vulnerable to log for Jay and you're telling me we're not but we have to explain to them why we're not so let's have that conversation because it might actually just be faster to update the library and and let them feel good

about it uh than it would be to have all the customer support calls coming in where we read them the same script about why you don't actually have to worry about this in your rabid 7 or or whatever your your vul management platform is telling you so think about tech writers think about GRC people think about program managers and your security engineers and your security developers as all components of a really healthy security program um and if you're in a small Scrappy team where you don't have all of those skills identify sister teams and and sibling teams let's go with sibling teams that you can tap into and and partner with um I I had a team where one of my program

managers really needed some tooling development done for his program which was working with external partners and our own inhouse engineering team didn't have time for him for at least 6 to eight months and he was really frustrated because he'd already been waiting a year for these features so we found another team inside the company that had sh that his Partners were also their Partners they had shared interest in making these Partners really happy with the company and they had Dev resources and they deved the future for him huge win because he was able to go out and find like other resources in the company that could help so think outside your organizational boundaries if you

can if you have that opportunity to go and tap into a product manager who really cares about the customer experience and can help you out with some of those things if you don't have that in your security organization uh this usually uh raises some eyebrows I hate security champions programs um and I hate them because they're usually underfunded and similar to Dev SEC Ops we have Executives Executives love security Champion programs because in their mind we don't need as big a security team because we have security champions in the engineering groups I'm sorry don't those developers have full-time jobs already when are they doing security Champion work are you hiring more developers to make space

for that security work what is their security training what is their security support I have talked to so many security Champions who were developers who were excited about security and a couple years in they are so jaded they're so disappointed they're like my management wants me to rubber stamp risk decisions that from a security perspective I disagree with I have no goal around security all my goals around shipping features still I have no internal support or connection to other security Champions to share best practices and my only career path if I want to do Security is to leave my engineering team and go work in a security team security can't be volunteerism it is a it is a function

that the business needs to invest in and so when I start seeing Executives say we're going to do security champ we're going to hire a full-time program manager to curate this internal community and give them what they need to be successful we are going to put Security in their performance goals and their manager performance goals so that everyone is accountable for this and it's not just a nice to have you've got a security buddy um then I will get on board with the idea of security Champions I have seen companies do this extremely well and actually do those things actually assign a person who is taking care of that community and making sure that they're successful and having

growth opportunities and that it works well and they're phenomenal and they act as this diplomatic Emissary for the security team where the security team is having regular one-on ones and and group meetups like a quarterly we're getting the Champions together with the SEC with the security team because who's going to know better the future road map of the company and of the product than the people in the product team and so when the security team is feeling like they're isolated and not like they don't know what's going on I'm just in a cave and somebody comes and tells me two weeks before they're releasing or maybe two days before they're releasing oh by the way we have a product launch on

Monday I'm sorry what wow how is this the first I have heard about it um if you want to get out in front of those releases having a tight relationship with those those individuals that are in the team is incredibly valuable if your organization doesn't have a security Champions program and you're struggling to know what is coming down the pike so you can plan for it so you can feel more self-determination and control about I know what my priorities are for the next three months in terms of helping my product teams um find the product managers for those groups they know exactly what's shipping when um and if you're in a small and medium company

that doesn't have a product management team just because you're a security engineer doesn't mean you can't go schedule a one-on-one with the engineering manager and say hey engineering manager how can I better support you I would love to like can I get a look at your road map for the next 6 months and that'll really help you understand where you know what's going to be coming at your direction um but again one last thing about security Champions uh I ier to them as diplomatic uh ambassadors they're not our minions they're not like oh we'll just Outsource this to the security Champions like they're they're doing valuable work when they're uh appropriately supported and so you know

treat them like part of the team not you know us versus them kind of stuff um I would like everyone to read this one out loud we are going to stop rolling your eyes at compliance uh security by compliance is awful it absolutely is um when you have an engineering group that only does the minimum viable security that meets compliance so we can get this compliance certification um the security theater of a company that implements tools required for compliance and then shuts off the notifications and doesn't actually do them um those things happen and those are terrible and there are bad uh not bad but not helpful compliance uh professionals just like there are not

helpful Security Professionals but the concept of a compliance program is ultimately around customer trust there is no con consumer reports for software development and until we have actual uh s bombs software build of materials to tell our customers exactly what is in a product the only way a customer has to know you did the right things for software security is you got a compliance certification this is how I validate without saying hi I'm interested in purchasing your product I would like to interview your engine engineering team and look at your Dev Pipeline and I'd like to see your ticket backlog to see what kind of issue no customer is going to do that and no sales team is going to

let them do that the easiest way for a customer to know you have done the right security things is that compliance certification and if we are doing the right things for security compliance shouldn't be hard there's a lot of bureaucracy involved there's a lot of paperwork involved and there are a lot of really interesting startups trying to solve that problem now to make it less painful to make uh sales enablement easier there are platforms being built for a customer to say I'm interested in your product I have a questionnaire well you know what we've pre-answer all of the questions that customers have ever asked us ever here you go here is the standardized format so there are

improvements in this area but if we make compliance our enemy uh we're missing out on a potential ally to help us get the right things done for the company because secure software should just be compliant and so just as we have secure by Design we should have compliant by Design as well and so they're they're a useful partner for us to work with so another thing that we in security need to do is really redefine our perspective very frequently we are the house of no we tell the engineering team no you can't do that um we also tell customers no you can't do that um we say no a lot and that's why people avoid working with us

um because we're always saying no we're we're the we're the you know traffic cops um and this ends up being somewhat destructive to our ability to influence the business and build relationships ultimately security is just QA we're just QA we are all about quality engineering and what's funny is if you talk to developers about quality engineering they get fired up yeah we do quality engineering we we are we are good developers no one says I write crap code it's fine uh they're they they want to write good code and quality code is reliable doesn't fall over every day uh it is accessible It is Well documented and quality code is secure so if we stop

writing security standards and we go work with our engineering partners and Architects and say hey I love your engineering standards can we integrate some some security things in your engineering standards now we're not other we're us we are focused on how do you develop quality code you don't you don't have to go look at a separate standards document a separate policy document and now it also aligns to those Architects accountabilities as the architect for this product I am accountable that we are meeting our engineering quality benchmarks well those engineering quality benchmarks now include things like secret storage which is where you want it to be where the engineers are working it is in their workflow Behavioral psycholog ology has

concepts of rewards and punishments Security's always showing up with punishments and negative reinforcement we are always saying no policy compliance rules standards we're never saying here's this great thing you can do with your with your product with your engineering here's how we're going to enable the business and so we have to think about the what's in it for them a little more instead of just for us us and that's really hard because we're expected to be perfect every time all the time and if the engineering team says I accept the risk on that issue I don't think it's real uh it's a theoretical risk it's highly unlikely and you're like no I'm pretty sure it's highly likely I don't

have an offensive researcher on the team that can go build a POC of exploit code but we think you should fix it and they're like we're going to accept risk and then 6 months later it gets popped a you're the one working overtime on incident response now losing your weekends and holidays and evenings because you're the cleanup crew and everyone wants to know how did this get shipped why didn't we catch it sooner why didn't you argue more compellingly that we can't accept the risk on this somehow it always still comes back to us so it's really hard it's I'm not trying to like trivialize how hard this is to make those tradeoffs um but we have have to we have to start

taking those chances and educating our leadership teams I'm hoping some of you here today are in leadership teams and can take this back to your business and be like hey it's okay if the security team isn't perfect all the time because no no one is um and if you want perfect all the time from your security team you are creating that friction that inhibits Innovation you have to take some calculated risks to get products out in Market and say you know what it's okay we're not going to fix this before we ship it's not critical but it is pretty important and we need to get it out within the first quarter after we launch and then that actually has to

happen uh the engineering team has to not just keep punting that down the road and so it's that relationship you build with the engineering teams I had early in my career bought into the bias that security is special and different and more important than QA and uh in 2014 a friend of mine uh we had an argument it wasn't like a shouting argument it was just you know spirited disagreement because he was like security is just QA and I'm like no it's not these are exploitable vulnerabilities and we have to protect people um and uh now 10 years later I'm like nope he's right he's right it's just QA and most companies nowadays don't even do QA they've also shifted

that left to the developers uh and to their bug Bounty programs and to their security teams and so if we if we think about it that way where it's our job to make sure that quality is getting out uh to our customers you know it it helps us reduce the pressure on ourselves of security has to be perfect all the

time one of the problems that security teams have is we don't actually know the customers of our company because we're isolated in security we don't know where Revenue comes from what what customer segment drives the most Revenue what product drives the most revenue for the company what do these new features unlock in the upcoming quarter we're we're usually extremely isolated from the sales team to understand what questions are customers asking the sales team about our products do any of them even ask about security are they asking about security features are your customers asking about when are you going to support SSL that might be one of the most important questions customers ask because they don't want to

implement MFA because it's a pain without SSO and so if you don't support SSO you're not letting your customers secure your product in their environment and so that might be the question coming to sales is that question then getting to the product teams can you help bridge that to say hey product team I know you're working on this cool new generative AI feature did you know how many sales we could unblock if we support SSO this quarter and so that gets more into the secure by Design but now it's datadriven secure by design that drives revenue and so how can we help bridge that Gap and get more security features in that will prevent incidents for ourselves and for

our customers by understanding what our customers care about if you're if the majority of your customers are uh pay as you go startup clients and and not big Enterprises that might change the security features and the security controls that you need to care about um and and how you allocate your resources in in your security team so take some time to get to know your customers I had a uh engineering team come to my team once and say we need to change the Authentication Protocol because it's causing problems for some customers and we basically want to do all these things and my team sat there and and talked to them and were like you can't do any of

those teams you're everything that we do about identity uh and access into the product you're weakening and uh about two weeks later I was at a customer conference and I ended up talking with one of these customers they're an mssp and so they're using our product for multiple additional customers and every time they had to log in a new customer in our platform they were going through like it took them five minutes to log into each one it was I'm going to log in in the application and then I have to go get a code from my email and then I go back to the application and I enter the code and it sends me another email that I then have

and I'm just I watched the customer workflow and that's when I understood the problem even the engineering team didn't understand the customer problem and within two minutes we're like oh well this is exactly how we could fix this for you without compromising the security of the login experience and so frequently companies are afraid to let the security team talk to customers because we're scary um but it doesn't have to be that way and so if you can find somebody in your sales or customer success team that uh you can build a relationship with see if you can go talk to a couple customers go to a couple customer conferences or events or places where your customers congregate

and uh just chat with them and see what's what's important to them this one's real real hard because of what I said earlier about us having to be perfect all the time but we can't we can't be perfect all the time our product teams can't be perfect all the time we we will drop some things and so the question is what do we drop I've seen uh engineering teams being completely crushed by the weight of vulnerabilities that they have to patch um because they've got a terrible history of hygiene and maintenance and there's a new security head of security new ciso new team whatever it might be that came in fixed all the broken tools

and like Unleashed a nightmare of technical debt on the product teams and so saying to them hey we're in the amnesty phase right now we're going to give you time to get caught up we know you're not going to drop all development for the next 6 months to go clean up the last four years of technical debt and that's okay we know all of these bugs are going to go out of SLA we're not going to extend the SLA because the SLA is diagnostic to the health of our program but what I'm telling you is you're not in trouble let's prioritize let's focus how many security bugs can you fix this Sprint two great here are the two that I would

recommend can we get to three could we have a stretch goal of four how many can we get in there and let's talk about that and then let's go communicate to leadership what that risk is in our Consulting we have security teams that get really excited to bring us in to help them develop what we call the secure developer experience which is a security program that is devex focused and the engineering teams are scared that the Security Consultants are going to show up and make them look bad unleash a ton of new work on them and when I say well no actually we would love to have an airing of grievances we want you to tell us all the things that

you hate about your security team and that you are worried about in your product so that we can help do you understand that one of our recommendations might be for the company to hire more application Engineers on your team and they're like wait what we might get more headcount out of this and I'm like well what we're going to do is look at your priorities and the security team priorities and help you escalate them to leadership together because it's leadership that needs to make these tradeoffs you can have the fature or you can have the security given the current team size or you can give us more resources to do both and the idea that the engineering

and the security teams would escalate something together doesn't cross their mind and so this is a skill that we need to learn to really enable uh the business and enabling the business means speaking the language of the business what is product L growth most security teams have no idea what product Le growth is they don't they don't know these aspects of Revenue generation or what leadership cares about what goes to the board what is a risk register um these are things that if you're early in career probably don't you know this might be a little Advanced but when you get into certainly senior and principal and Leadership levels you need to learn the business outside of

security because you can't be a partner to the business if you don't speak their language just like they aren't going to understand security nor are they going to take the time to understand security if you aren't meeting them halfway because at the end of the day our job is to enable customer trust can customers TR trust our product and because we're QA and we're working with the engineering teams that's what we're focused on so all the decisions that our engineers make and that our company makes are focused on is this a trustworthy product customers can use in their environment can they share their data with us are we doing the right thing when we have an incident are

we communicating in a timely and transparent way so they feel like they can trust us if your customers 10% of the time if you're late on communicating or you're opaque on communicating an incident and they have to pull it out of you or they're like I don't know what's going on maybe I have to work all weekend on an incident maybe I don't were they affected weren't they I think they were if that's only 10% of the time the other 90% of the time they're still not going to trust you can I trust this as all of it um is there more I need to know and so we are that customer trust Advocate Within the company um and

that's another reason why it's so important to understand your customers and understand what they care about um because it's not always what the security teams care about so we can make this better uh by changing the way we work in this system Dev SEC Ops doesn't have to fail but we have to redefine the way security interacts in it um and and really meet our developers and improve their use experience so uh you know I I call it the develop the secure developer experience it's not my idea Dino Dai uh presented that at a conference in 2022 and I'm like that that is exactly it it's not about Dev Ops it's not about secure development life cycle it's about

the dev ux to do the right thing and so let's make it easy let's create these paved paths for them where why would I roll my own crypto there's like a really easy Library I can use right here why would I create a completely new secret storage you know model we have Hashi Corp it's already implemented it's already approved we're going to use this thing whatever the tool might be if they really really really want to go off-roading and get off this beautiful eight Lane paved Super Highway we've created for them well that's what the security teams therefore we can help them but we don't have to date everything if your feature is low risk

and it's a minor revision maybe it doesn't need an updated threat model full Security review in pentest maybe that one's okay to go I'm sorry you're changing authentication yeah we should do a review of that um and so really making those risk-based decisions where we can partner with the business versus be a gate before release blocking the business um so I have a couple minutes left if there are any questions uh and thank you so much for coming to my rant on devs Ops and how we're doing it wrong um and I hope that this will help everybody think about how we can do things differently [Applause]