Moving Faster - Securely. Why Your Org Should Add Security to your DevOps Program
Amanda Fennell: Thanks for tuning in. If you enjoy today's episode, please rate and review us wherever you get your podcasts.
Amanda Fennell: Welcome to "Security Sandbox." I'm Amanda Fennell, chief security officer and chief information officer at Relativity, where we help the legal and compliance world solve complex data problems securely. And that takes a lot of creativity. One of the best things about the sandbox is you can explore and try anything. When good tech meets well-trained, empowered employees, your business is more secure. This season, we're exploring ways to elevate the strongest link in your security chain - people - through a creative use of technology, process and training. Grab your shovel, and let's dig in.
Amanda Fennell: In today's episode, our sandbox heads to the deployment pipeline for a conversation on the who, what, when and why of a DevSecOps program and how it adds value to your business. And it's going to answer your main questions, how can you encourage buy-in and adoption? Joining me today are Marcin Swiety, Relativity's senior director of global security and IT, and Raphael Theberge, director of security integrations. so grab your DORA metrics, your source controls and staging environments, and let's dive in.
Amanda Fennell: We're going to jump right in to the topic at hand. It's - we're not going to do a shot every time somebody says DevOps or CI/CD. It's super close. I know. Raphael's nodding like I thought that's what I was here for. OK. It's super close. But no, we're going to go through this in the beginning, though. How would you describe DevSecOps to your grandparents? Raphael.
Raphael Theberge: All right. Well, the first thing I would say is that I simply wouldn't, I wouldn't do them the disservice of bothering them with that.
Amanda Fennell: (Laughter) OK.
Raphael Theberge: But, you know, for argument's sake, let's say that I would do it. The closest analogy that I would use is probably comparing it to having a cookbook, where, you know, you open up your cookbook, you have a picture of here's a meal that you want to prepare. Whatever it is, doesn't matter.
Amanda Fennell: You chose the worst thing to do on a show with me, by the way. You went for cooking? Let's do this. Let's do this. Keep going.
Raphael Theberge: This is not an accident.
Amanda Fennell: All right. Smart man, OK.
Raphael Theberge: And you really have two different components in your recipe book that matter. You have a list of ingredients and preparation that's needed, and you have steps to build it. And the way that I look at the DevSecOps portion is really as those two aspects. You have the build steps, which is your recipe of what you do to achieve your final product, which is a meal in this case. And your dev - your SecOps that you add into it is really the - all that has to do about the preparation, all the surrounding, oh, you prepare your ingredients, what ingredients you use, what quality you want, what's the nutritional impact of it? Everything from A to Z stems from that. And I'm stretching the comparison a little bit, but bare in mind...
Amanda Fennell: I'm about to dive into it. Yeah. No, if you were pandering to the chef in me, like, I'm interested in this, so we're going to go into this. I have some input on this one. Marcin, do you agree, disagree? Does this resonate with you? Because I'm about to double click on it.
Marcin Swiety: To some extent, yes. But no. I like to make a switch here. I don't see how that differs, though, from usual approach, right? And there is something about DevSecOps that is actually different, that actually allows you to run faster, make stronger outcomes or more predictable even at some point. So I - what is the difference in the recipe and the ingredients between what we did old style and we do right now?
Amanda Fennell: This is actually what I was going to double click on, Marcin. I'm not surprised you honed in on it. But here's the thing. So with cooking, you know, before you start, you put together your mise en place, you put all the recipes in place, you get everything situated. And then once you've made sure everything is there - trust me, my kids are always trying to get me to make pancakes. And I always tell them, do the mise en place. Let's see how this goes.
Amanda Fennell: So they get everything together. They set up all their ingredients and everything. The difference from my very, you know, different perspective per chance is that instead of waiting for all of the ingredients to be put in place first, you start running. You would start the cooking and start the movement, and you would pivot as needed. And that's how I feel about the DevSecOps is that it moves things to the left. You're not waiting for a step to be completed to go to the next one. And I think this is an interesting topic for the three of us, because, Raphael, you were - it's like a Batman reference - you were born in DevSecOps, molded by it, right? We were not. We built, created, made this entire thing and then said, oh, crap, we probably need to figure out how to implement security more to the left. So that's the way I'm approaching it. Correct Marcin and I, are we wrong? Is that an incorrect way of looking at it?
Raphael Theberge: I don't think that it's wrong at all. I think that with my analogy, what I was showcasing is how do you make one instance of a meal? Now, when you shift this into a business context and you want to make not one, but potentially, let's say, a million a day, for argument's sake, then you need to have those steps very well-defined. You need to be using the same structure everywhere. You need to understand every single step and all the complexity it entails all throughout out so that you can upscale it and truly change from, you know, grandma's kitchen to a manufacturer.
Amanda Fennell: Oh, so now your grandma's cooking. OK. That was a good way to talk to her then. That's why you chose that, too. You're like - you're cooking. So DevSecOps promotes faster development of secure code base. A-ha. I see a flaw. Everyone in technology has latched on to this term. So, for instance, I have more than just security; I also have IT. IT has latched on. Oh, we have to do DevOps. We have to do - first, OK, let's go back for a second. DevOps versus DevSecOps. You know I've gotten into a fight about this one many a time. Did I back the wrong pony? What are we supposed to call it?
Raphael Theberge: The question of naming convention is a very difficult one. That term - and both those terms, really - have been co-opted by so many other entities to turn it into marketing material, to make it more accessible. And there's a lot of good reasons why. But the meaning has been diluted over time. And really, it can be twisted and turned to mean whatever you want today.
Amanda Fennell: (Laughter) That's the best answer for - it could be whatever you want. So you're going to let people choose their own adventure. Marcin, what do you refer to it as?
Marcin Swiety: I think my concept of what DevSecOps would mean, actually, and in that term is combing of those three functions and interests together and collaborating. And I think when we - when you go back to your recipe analogy, Raphael, I think there is something that just, you know, popped into my mind, when my grandparents were, you know, making dumplings. So I remember every now and then, there was a, I would say, soccer game on, and my grandparent would love to watch that. But he had, you know, a duty to, you know, assemble the dumplings.
Raphael Theberge: Oh, yes.
Marcin Swiety: And if you would take that task specifically out of the kitchen to the living room, where the game was on, somehow the entire process, although it was streamlined - like, this is a huge adventure for an entire family to prepare a lot of dumplings for coming weeks. It kind of broke because there was no closed feedback loops on how fast we are going, how much we need more minced meat, how we are going with boiling the dumplings and so on, so forth. And I think that what it actually means for me, that kind of closed feedback loops - very short sight of what's working, what's not working, what we can align and adjust. And we are still perfectly aware of what the exactly - exact steps are, although we need to adjust the speed, the process, and we need to synchronize together. So I think that what DevSecOps means to me.
Amanda Fennell: So move faster, move better, move more securely. Why are people not taking the time to go and do this and implement this?
Marcin Swiety: Oh, this is a good one.
Amanda Fennell: I know.
Marcin Swiety: I think the biggest - I found, the biggest detractor to this or the biggest wall that we need to break through is we've always done this this way. I think that's the common theme that we have in the entire industry. And there is a good reason for that. What worked so far, it's really hard to knock that down. And we have a saying in Poland that if it works, don't touch it because it might break.
Amanda Fennell: (Laughter).
Marcin Swiety: And I think that's one of the...
Amanda Fennell: It's pessimistic, as expected. I love it (laughter).
Marcin Swiety: Yeah, of course. Of course. Like, I'm born in Portland.
Amanda Fennell: (Laughter).
Marcin Swiety: But that's one part of this, of why people are not doing this, you know, largely and everywhere. It's because there is another way. There is a contextual, historical point of view on how things are being done at this moment, in this specific moment, for a specific company. And that type of switch is actually something - kind of redefining the relationships, the product, the outcomes and, more specifically, the responsibilities and ownership. And that's, I think, what is the basis for how we are not doing it everywhere in every company and everyone.
Raphael Theberge: I pretty much agree.
Amanda Fennell: Raphael, you've come to a new place. Yeah. How's it been for you? Is it same impression?
Raphael Theberge: I think that there is a bit of a fundamental truth in that changing the status quo is difficult. It's an inherently difficult proposition. Even if you have the best intention in mind, you need to be able to see your vision through. You need to be able to showcase, yes, this will be a meaningful endeavor. And for you to cast that vision to everyone around and for them to understand that, they need that baseline understanding of why does this matter? So there's a lot of education that needs to happen in terms of, why should I invest in this? What are the expected return on those investment? And then that's both in time and quality of life and predictability. And truly, fundamentally, it's really a matter of education. And for some people - and maybe a lot of people; I'm not sure - seeing it matters way more than hearing about it. And being able to experience, OK, here's what it is to operate in a company that does DevSecOps correctly - or "correctly" is, quote-unquote, right? But...
Amanda Fennell: But you said DevSecOps. Just saying. So that's how you said it. But - (laughter).
Raphael Theberge: Yes. Yes. Yeah, fair enough.
Amanda Fennell: Caught you. All right, got it.
Raphael Theberge: Yeah.
Amanda Fennell: I love a couple of the things you've mentioned, though, because I think it's a surprise to hear you speak so much of this about, like, the business side of it. I think a lot of people expect us to just speak about the security and, like, just get stuff secure, and that's all we care about. But you're clearly coming at this from a business perspective of how to move faster and more efficiently to accomplish better business needs and so on. So talk about DORA metrics. And I assume this is not Dora the Explorer. So I'm ready. Teach me. What do we got?
Marcin Swiety: There are four metrics inside of the DORA set. This is a set that is actually one of the ways how you can measure success and measure how you trek towards this journey. There are four of those. Two of those are speaking solely about speed and maybe even frequency of how you deliver. And later two are talking about what happens when something goes wrong and how often that happens. So you have the deployment frequency. You have lead time for changes. And the other two is meantime to recovery and change failure rate. So these are the four basis metrics that I think the entire industry is either familiar with or actually uses to track towards DevSecOps achievement or advancement or maturity, whatever we like to call it.
Amanda Fennell: So, Raphael, like, if you've got these metrics, like, you were speaking all business-y earlier - so taking these DORA metrics, which I have to look at as well, what am I supposed to be taking away from it? I just want to see green is good, or is this providing some other value that I need?
Raphael Theberge: Well, green is good is certainly one part of it, obviously. But going more in-depth, I think it speaks to, how do we monitor those metrics? Like, we have a metric. The name is called lead time to change. All right. How is that being measured, and what does it encompass? Is it actually measuring the entire time it takes to go from, you know, keyboard on hand to a change on the production environment? Or is it only a subset of that? And I think that when we speak of the distinctions between DevOps and DevSecOps, it's really about englobing the entirety of the pipeline, including all of the security characteristics, into those metrics.
Raphael Theberge: So instead, you will have the same metric. It will have the same name. But what it means, what it encompasses and how it is being measured is different. If, for example, you take your lead time to change and you factor in all of the security analysis, security fixes or whatever is needed, your average lead time to change may be a little bit higher because you're now encompassing a few more things. But it will be way less spiky because you won't have those big anomaly when there's a security event or something has been detected. You smooth out those metrics over time so that you can better predict future performance.
Amanda Fennell: So it's not just for engineering. It's not just for security. It's for all teams that can do this, and they can approach these metrics and try to measure moving the needle over time. Marcin, I'll start with you, because I know Raphael is going to have something very exciting to talk about on this topic, but has this impacted the relationship between security and engineering? (Laughter) I say that laughing because I'm waiting to see - that was me taking the grenade pin out and throwing it over there.
Marcin Swiety: Yeah. This required a huge redefinition of what the relationship is actually about. And there's a lot of friction in most of those redefinitions because it touches the ownership and responsibility set. And as soon as that both of those sites are three sites or four sites, depending on how we are built and how we are doing our business, those sides to this, as soon as they realize that they are co-owning the success and co-owning the future of their component, of their growth and ultimately their business, then that redefinition actually starts to get better. And that's properly set up as a north star.
Marcin Swiety: So what I'm trying to say here is I've seen a lot, especially when I looked at my consulting days on different companies from different industries. That type of relationship can be love-hate. In most cases, it's actually that, love-hate with a little bit of skew towards hate, because security has been known as gatekeepers, blockers or even no-sayers in a lot of engagement that I've seen in the past in the other companies in, I think, every industry that I worked for. And this is interesting because what DevSecOps is supposed to build is a true partnership. And I think that's the key change that we need to look for. But I would hope to take your point of view, Raphael, on this side because...
Amanda Fennell: OK, so let's have the guy who I stole from engineering into security, by all means. Is it going to need friction over there, buddy?
Raphael Theberge: I think, you know, if I go back to the original question, how will it affect, just agnostically, the relationship between security and engineering? It depends on when and how it's done, primarily. Depending on what stage you're at in your company, if you're doing it as Day 1, joining a startup, you're four people in a garage somewhere, there will be no consequence. There will be no impact. It will work, and that's it. If you are a multinational corporation and trying to go from zero to one, now there will be an impact. You're trying, like I've said earlier, you know, changing the status quo. You are enacting changes. There will be friction during that period of change.
Raphael Theberge: The intended outcome at the end is really to reduce the amount of friction between those two things through various automated pipelines and various automated processes. But it doesn't reduce the total amount of interactions. It changes them. Those interactions will still happen, probably through some automated systems. But these will capture what I like to call the more toil-level tasks, where people are doing things that are tiny, nitty gritty things that need to be done over time. And by ideally tackling those in an automated fashion, you're upscaling the conversation between your security group and your engineering organization to be working on much harder and deeper problems, like architectural and deep meaning conversation that will change how your company functions and essentially create more time and more space to have those deeper conversations. And yeah, those will be fraught with back-and-forth, and not everyone is going to like it, but it needs to happen. And those are the truly impactful decisions that will change the course of how things go.
Amanda Fennell: So all of these things that are impactful - I just want to pull back because there's a couple of things that I'm going to say is, like, kind of the - what do they call? - like, an elephant in the room here. You have to get buy-in for people to do it. We talked about, a few minutes ago, that it's - how - where do you - you know, who's doing what? Where are we going with this? What am I looking for from DORA metrics, etc.? But then also, why aren't people doing this?
Amanda Fennell: Let's talk a minute for the buy-in. I think everyone thinks the buy-in has to happen at the executive level or the functional leader level when actually that's where we struggle the most, is that it's not there. We need to get buy-in from the actual engineer who's hands on keyboard because they have, as we mentioned, a list of priorities, and this is not No. 1 priority. To stop the firehose that's coming at them, they're going to have to take that for a while, while they go and fix this, right? And then everything will smooth out. But they're not convinced that's going to happen. So, like, there's question about buy-in here for DevOps, DevSecOps. So there's this idea here of, like, we got to get buy-in, we got to get buy-in. It's not from us. I think it's from the engineers. What would you two say?
Raphael Theberge: I would tend to agree, but I think that we can argue over the definition of buy-in in this case. You can be, you know, autocratic and say you must now use pipeline X to achieve Y, and it is what it is. That will create some friction, but it is possible. Now, if you phrase it differently, and you say, hey, I've created this pipeline X, you can choose to use it or a subset of it, and it may well improve on your delivery time and let people self-serve and self-onboard into it and get to see the progress by themselves. And not everyone will be impacted immediately positively by those changes, so the level of experience of the specific engineers will matter. Ideally, you want to have people with a little bit more seniority go into it and really iron out the key details, and then your more junior-ish staff will get to benefit from it significantly more.
Marcin Swiety: I would say I agree with 100% that which you just said, but I would actually add also that the buy-in is - does require a strong support from leadership and management. This is not a buy-in type of relationship. This is a, I guess, strategic decision at some point. You have to run faster. You have to make stronger, more robust software, and you have to eliminate the friction. So you cannot maintain the speed with, you know, growing company, more complexity, more products, more components. So this is, like, a business decision on a higher levels of managing the entire thing.
Marcin Swiety: But I would agree that in the lower levels, this is buy-in to enabling them to see the benefits. But also sometimes every now and then, you need to step in and say that you cannot take your, you know, dumpling assembly (ph) in front of the TV because it will not work. You have to be responsible for kind of the entire process. You have to be owner of the future of your component, your code, regardless whether it is about the maintenance, whether it is about a security. You build it. You are required to be projecting and protecting its future. And I think that's a little bit different than the sole buy-in. Sometimes you just need to kind of create a space where that's kind of a requirement because otherwise that ownership might blur itself very, very quickly.
Amanda Fennell: So buy-in aside, once you decide, what's my timeline look like for this? Can I get DevSecOps in six months? Like, what's the situation here?
Raphael Theberge: Marcin, you want to go first?
Marcin Swiety: Yeah. I don't like to talk about timelines.
Amanda Fennell: So it's my favorite thing, by the way. In the kitchen, I constantly ask the sous chef, and I'm like, OK, so you want me to do this with the risotto. How long until I start? He's like, I don't like times. I don't know why you always ask me times. I'm like, 'cause that's - I'm a CISO. That's all I want to know, is how much time?
Marcin Swiety: But I will say, you definitely can start now. That's - the timeline that is - you have full control of is you can start now. There's nothing preventing you from actually starting to define the roadmap, the principles. What actually DevSecOps means for your organization, what type of metrics you are going to use, when you're going to measure success - you can start it right now, and as soon as you do that, you will see immediate changes to what you are aiming for and what you are building. Of course, there is tool, process and tech - right? - to every adventure we undertake. But I think this one is actually quite easy to start for a prior decision. Of course, implementation - it will take time. Six months - I wouldn't say that it's feasible to really go fully into every aspect of a living, breathing system that you've built over, you know, decades. That would be probably a quite challenging task to have 100% completion on. But I would say you would be - six months would be pretty enough - like, quite enough time to get significant advancement to be able to deliver faster, quicker and much more robust pieces of software that you care about the most.
Raphael Theberge: I find myself agreeing and disagreeing at the same time.
Amanda Fennell: Isn't this how we started, was you both agree to disagree with each other?
Raphael Theberge: It is, right?
Amanda Fennell: OK, yeah, here we go.
Raphael Theberge: The - in terms of timeline, let's assume we want this to happen within six months. All right. Well, what are we starting from? If we currently are 90% of the way there, yeah, of course, that's trivial. If we're starting from scratch, it depends on the size of your company. It depends on what your other goals are going to be, how much resources, how much money are you going to put into it - all those details. But the part to me that makes it difficult to stick to a specific schedule - there's three components to all big transformation. You have your deck. You have your processes, and you have your people. And tech and processes - you can change that over six months. That's more or less trivial. Changing people's mindset over a six-month timeframe is an extremely challenging endeavor - perhaps not impossible - certainly not impossible, but very challenging.
Amanda Fennell: I think that's an interesting point, though, because sometimes I just wish I'd had the two of you from my first day at Relativity 'cause I feel like I would have gotten a lot done a lot better a lot sooner if I had. But you make this comment about, like, changing people's minds and so on. Yes, it takes time. I think it depends on how much that muscle was built originally. And so, I say this because, like, you could throw anything at the security team, and their response is going to be like, OK, Amanda's crazy again. Like, let's do it - whatever. And they kind of just work through it and get through it, right?
Amanda Fennell: And I love this quality in people that you either - with change, you either struggle with it, maintain and get through it or thrive on it. And I feel like our security team - more people than not thrive on the change. So we threw a lot of DevSecOps into there, and everyone was like, OK, here we go, right? Here is the next journey. But there are a lot of people in the org that struggle with it. And I think because probably they think it's because they need to create a playbook. And they don't see a lot of value, and they don't see the, you know, the low-hanging fruit and stuff like that. So yes, I think the culture change is probably a big factor, and that's an unknown until you get started because you don't know how receptive people maybe are. But you could prepare yourself by making them receptive to change by constantly changing things up on them previously...
Raphael Theberge: Yes. Yes.
Amanda Fennell: ...Which we do all the time. Like, you don't always know what's going on because we throw some weird things at people, and they're like, OK, so - all right. So I think I've got some main points I'm going to wrap this into, and we'll see if we agree to disagree on this one. It seems like closed feedback loops are still important. You can't move too fast without this clear vision and guidance as to what's working and what's not. So you don't want to let the dumplings break. I'm super hungry now for dumplings, Marcin, but OK.
Marcin Swiety: Counterpoint.
Amanda Fennell: Always, right? This is next up. To sell the DevSecOps idea - seeing is believing - you need to see the process and work and the speed that comes from it - the value that's delivered. And it has to have - like, this upscaling conversation has to work on deeper problems. It can't just be you're going to make this move faster. It has to be you're going to fundamentally make things move faster. And I feel like there's a strategic part here, too, about reducing - it doesn't reduce the total number of interactions you're probably having between teams, but it would change them. And Marcin, it sounded like you were saying it's a different dynamic, and that, you know, you just have a changed conversation as opposed to the blocking. And it's much more of that partnership comes out of it 'cause we both want the same thing. We want to move faster - securely. I always like to put comma, securely.
Raphael Theberge: Yes.
Amanda Fennell: And it feels like this is that great energy, right? But - all right, so these feel like my three main things. If each of you gets one main thing that people will walk away from and say, DevSecOps means this, what would you say? So it's not your grandma, now. This is the people who are listening to the podcast - which might be your grandma. I don't know. What are you going to say is your one takeaway?
Raphael Theberge: I would say that it's all about upgrading the level of discourse across your company and being able to move out of the tiny details - that are important and need to be handled - into higher-order conversations and higher-order problem solving.
Marcin Swiety: And to pile on that, I think, Raphael, I would agree here - of course, here - only here.
Marcin Swiety: One hundred percent, but...
Raphael Theberge: Only, yeah?
Marcin Swiety: I would add that the co-owning of the success of the endeavors and undertakings that any business takes is also key. So it's removing the frictions, increasing the depth of those conversation interactions and, finally, co-owning the success by every team that is involved.
Amanda Fennell: Wow. So finally we have an agreement.
Raphael Theberge: We do.
Amanda Fennell: We worked so hard to get an agreement. But I love to end on a quote, and this particular one might be the only quote I'm ever going to use by Ralph Waldo Emerson. I can't stand Emerson and Thoreau and Walt Whitman. This is, like, not my area at all. If you had told me it was, like, a Frank Herbert discussion, I can follow sci-fi. If it's Cthulhu or Lovecraft, I've got it. But OK, Emerson had his moments. So he said, do not be too timid and squeamish about your actions. All life is an experiment. And the more experiments you make, the better. I think that's going to capture my DevSecOps mode right there. Let's make an experiment.
Raphael Theberge: That's very nice. If I may follow that, I also have my own quote ready to go.
Amanda Fennell: Is this tattooed on your arm? 'Cause, like, if it's not... (Laughter).
Raphael Theberge: It's not tattooed on my arm...
Amanda Fennell: All right, let's do it.
Raphael Theberge: ...Although I might consider it. I'm translating it from French, from the illustrious Marie Curie.
Amanda Fennell: Oh.
Raphael Theberge: In life, nothing is to be feared. Everything is to be understood.
Amanda Fennell: Oh, wow, Raphael - talk about the feather in the cap. I can't come back from that. That is awesome. Thank you for that. Gentlemen, it has been a pleasure. I have enjoyed spending some time with both of you where we were not having to just get work done. So thank you so much for joining and giving us some time to talk about your favorite topic.
Raphael Theberge: Thank you so much for having me.
Marcin Swiety: It was amazing.
Amanda Fennell: Thanks for digging into these topics with us today. We hope you got some valuable insights from the episode. Please share your comments. Give us a rating. We'd love to hear from you.
Unidentified Person: Security Sandbox is produced by Relativity. Our theme music was created by Monarch. Find us wherever you listen to your podcasts, or visit relativity.com for more episodes.