Subscribe to Security Sandbox
What is DevOps? What’s CI/CD?
Why should you care?
That’s the topic of discussion for this month’s episode of Security Sandbox, as Relativity CSO Amanda Fennell chats with Marcin Swiety, Relativity’s senior director of global security and IT, and Raphael Theberge, our director of security integrations. We’ve embarked on this journey as an organization this year, and the group had a lot of insights to share about encouraging buy-in and how this approach adds value for the business.
Listen to the full episode below or in your favorite podcast app, and scroll down to read a partial transcript.
Partial Transcript
Amanda Fennell: How would you describe DevSecOps to your grandparents?
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. But, for argument's sake, let's say I would. The closest analogy that I would use is probably comparing it to having a cookbook: you open up your cookbook, you have a picture of a meal that you want to prepare. Whatever it is, doesn't matter. 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. The way that I look at DevSecOps is like that. You have the build steps, which is your recipe of what to do to achieve your final product.
Amanda: If you were pandering to the chef in me, I'm interested. Marcin, does this resonate with you? Because I'm about to double click on it.
Marcin Swiety: To some extent, yes. But also no. I don't see how that differs from the usual approach, right? And there is something about DevSecOps that is actually different, that allows you to run faster, make stronger outcomes, or become more predictable at some point.
Amanda: This is actually what I was going to double click on, Marcin. I'm not surprised you honed in on it. With cooking, before you start, you put all the recipes in place, you get everything situated. But the difference here is, from my very different perspective, instead of waiting for all of the ingredients to be put in place first, you just start running. You would start the cooking and start the movement, and you would pivot as needed. That's how I feel about DevSecOps—you're not waiting for a step to be completed before you go to the next one.
Raphael: I don't disagree. 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—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 throughout, so you can upscale it and truly change from, you know, grandma's kitchen to a manufacturer.
Amanda: Okay, let's go back for a second. DevOps versus DevSecOps. What are we supposed to call it?
Raphael: The question of naming convention is a very difficult one. Both terms 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: (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: I think my concept of what DevSecOps would mean, actually, is combining those three functions and interests together and collaborating. Going back to your recipe analogy, Raphael, I think of when my grandparents were making dumplings. I remember, every now and then, there was a soccer game on, and my grandparent would love to watch that. But he had a duty to assemble the dumplings. So if we would take that task out of the kitchen to the living room, where the game was on, somehow the entire process—this huge adventure for an entire family to prepare a lot of dumplings for coming weeks—kind of broke because there were no closed feedback loops on how fast we were going, how much more minced meat we needed, how we were going with boiling the dumplings, and so on. That kind of closed feedback loop—a very short sight of what's working, what's not working, what we can align, and adjust—is what we need to synchronize together. So I think that what DevSecOps means to me.
Amanda: You have to get buy-in for people to do this stuff. Everyone thinks the buy-in has to happen at the executive level, but I think where we struggle the most is getting buy-in from the actual engineers. They have a list of priorities, and this is not number one. What would you two say?
Raphael: I tend to agree, but I think that we can argue over the definition of buy-in in this case. You can be 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, you could phrase it differently, and 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-onboard into it and get to see the progress for themselves. Not everyone will be impacted immediately by those changes, so the level of experience for the specific engineers will matter. Ideally, you want to have people with more seniority go into it and iron out the key details, and then your junior-ish staff will get to benefit from it significantly more.
Marcin: I would say I agree with that which you just said, but I would actually add also that the buy-in does require strong support from leadership and management. This is not a buy-in type of relationship. This is a 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. Sometimes you just need to create a space where that's a requirement because otherwise your code ownership might blur itself very, very quickly.
Amanda: What one takeaway on DevOps do you want to leave people with today?
Raphael: 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: I would add that co-owning the success of these endeavors any business takes on 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: 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. I can follow sci-fi. If it's Cthulhu or Lovecraft, I've got it. But 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: That's very nice. If I may follow that, I also have my own quote ready to go. I'm translating it from French, from the illustrious Marie Curie. “In life, nothing is to be feared. Everything is to be understood.”
