Software Security Gurus Webcast Episode #11: Patrick Debois

Matias Madou:

Welcome to the Software Security Gurus Webcast. I'm your host, Matias Madou, CTO and co-founder of Secure Code Warrior. This webcast is co-sponsored by Secure Code Warrior and for more information, go to www.softwaresecuritygurus.com. This is the 11th in a series of interviews with security gurus and I'm super pleased to have with me today, Patrick Debois. Welcome, Patrick.

Patrick Debois:

Well, thank you for having me, Matias.

Matias Madou:

Of course.

Patrick Debois:

It's fun to be here.

Matias Madou:

Of course. Patrick, do you mind sharing a few words about yourself?

Introduction

‍

Patrick Debois:

Sure. My name is Patrick Debois and I have gray hair, which means I've been in this industry for a long time. When I studied, I was working on the internet in 1993, when I started my first thesis to finish off my studies. And since then, I've been passionate about the internet and I've over the years done many roles from developer, from operations, to management, to delivery manager, to operational manager, to security person. I think part of that kind of culminated in when I was taking more of agile operations and that led into DevOps and that's where a lot of people might know my name from because I've been promoting DevOps before it was DevOps by doing the first conference in Ghent. And since then, I started listening more about stories throughout that and helping to get the stories out and get people excited.

Matias Madou:

Yeah, exactly. So the first two things that you mentioned is like, "Hey, I have taken roles as developer, as operations," and then you said a lot more other roles but it's interesting to hear that the first two are developer and operations. As you rightfully said, 2009 in Ghent, you started DevOps Days. Nobody had ever heard about DevOps before and that's where you're famous for. Wikipedia says you're the inventor of DevOps, so how did that happen?

Patrick Debois:

Well, you shouldn't believe Wikipedia, right? I'm not the inventor of DevOps as what the older practice is. I, by accident, called it DevOps Days because Agile Operations and Development Conference was very long. I think at the first event, I didn't realize DevOps was even a thing until somebody wrote up that they saw all the excitement around the collaboration happening in the room. I think I was just jealous from agile people, how they collaborated and got better and especially how they were more happy at their jobs doing things. And in operations, we had this bastard operator from hell mentality where everything was block, say no, it's hard, don't do that, you're stupid kind of that mentality that was there. I found it refreshing that the people in agile kind of ... We want to get better. We want to help each other. We want to kind of get the business involved, make sure we're building the right thing and building it right at the same time so that was my kind of early spark for organizing the first DevOps Days.

How DevOpsDays was born

‍

Matias Madou:

Interesting. So 10 years ago, security was the same thing. It was always saying no, it was always stopping the train, so developers must have a very hard time 10, 15, 20 years ago with operations and security, always having to stop them from doing their job, essentially.

Patrick Debois:

The interesting part is, like I said before, if you have done many roles, the one role you're in is the hardest always. If you're a developer, you think you're the hardest job in the world because you want to get those features out and nobody lets you. And then if you're in operational, you want to get the system stable and keep that running and everybody's against you. And the same thing is with security and management, looking at the costs and making sure you make money and then the engineers go wild by saying, "Well, we need this an A and B," but it's not cost efficient to reinvent your architecture every day, right?

Matias Madou:

Yeah.

Patrick Debois:

It's kind of counter intuitive. And so, that kind of ... This complaining, I mean the complaining, "Oh, the others are ... Our job is hard." It's not really hard in a way that we're not exceptional. I think what you need to realize is that we are all putting a certain pressure that makes the system work. If nobody would put the pressure of security on there, you might not be doing well on security. If nobody does pressure on getting features out, we might not win money because we're not doing features because everybody ... So this is a system that we're building balance in and we need those different aspects like focuses, but there is no one focus that could get predominantly because otherwise the balance is going completely wrong there.

Patrick Debois:

So that's kind of my more nuanced take if you get in all the other groups, because that's another side effect. If you enter one group, even though I had, for example, done development before and I entered an ops group, just by stereotyping because I'm now in the ops group, I know nothing about development. [inaudible 00:06:01] And that mentality of just you don't know your job because you're in another group or you don't understand this because you're in another group, that's still prevalent in many of the roles we have.

Matias Madou:

So essentially, we're asking people to stay in their lane, but essentially that's the wrong thing to do because we have to know what ... Essentially, it's better to understand what the other people are doing and how they are doing it than trying to stay in your own lane and only do what you're supposed to do.

Patrick Debois:

Well, that's the interesting thing. I sometimes joke 10 years ago, nobody was actually stopping you from talking to operations. Nobody was telling you not to do it. It was just the way we put ourselves in a structure that limited us. I think you can bring in Taylor and say, "It's like the organizational silos within factories and we brought that into the IT industry." So that's one thing, but I think another one is around technology and engineering. There's been a lot of focus around skillset and competence of technology. I know something better than you know and that obviously, if somebody is doing a different job, they cannot be as good as you at that job. But ignoring that their job is equally important, it's something that we don't to do because we're good at our job. We have that competence, the others have not so we tend to kind of make ourself uber the other which is not really helpful, that kind of perspective.

Matias Madou:

How does security fit in there? So first of all, you were in operations when you started DevOps Days. I thought you were in engineering at that point, but sounds like you were more operations and you were jealous of people that are cranking out features fast, and you were trying to figure out how to do that. You were able to do figure it out like, "Hey, how can we bring developer and operations together?" But in the last 10 years also security has to find its way into that DevOps cycle, if I can call it that way. How does it fit in for you? Where is security?

Where does security fit into DevOps for you?

‍

Patrick Debois:

I think it's interesting if having the perspective of the history over DevOps, I think from the first year people have been saying, "We need more security folks in here." It's not that we had forgotten them but I think the industry maturing-

Matias Madou:

You couldn't find them.

Patrick Debois:

No, no. It was more about the industry maturing around the delivery of features and stabilizing them. I think that after a while, we got time freed up that we can actually spend more time on security. It was a learning or maturity level going on in the industry. Now, if your job was security, obviously in 2009, you're already doing security and that was your main focus but a lot of the companies, they were struggling to get the features out. And then, by the pipeline that got better and now we started to worry more about whatever we're delivering is not only valuable for the business, but can we have all the security aspects covered as well from a business perspective?

Patrick Debois:

I think in that way, it is very similar to DevOps. You bring another group working together. It's funny, over the years I've seen front-end ops, I've seen UX ops, I've seen all the terms you can bring on ops. And now, it's like DevSecOps kind of collaborating. So that collaboration aspect is not so different from DevOps in general. Obviously, we're just barely scratching the surface, what that could mean on a collaboration tooling perspective. That is something we're finding out these days, like how does that fit in the pipeline? Because it can't be a stop mentality. We get more agile, more fluid at solving this issues or debates we have. But I think the one big differentiator is that it's way harder for security sometimes to build up the value case, features that bring value.

Patrick Debois:

I think we had the same problem with ops in the beginning. And now, everybody sees ops as a strategic thing where having a performance site, if it doesn't respond in a couple of seconds, then users get out. So gradually, that build up to ... I remember a blog post in 2010, like operations is the secret weapon, right?

Matias Madou:

Mm-hmm (affirmative).

Patrick Debois:

They kind of make the differentiator between both having the same side but both performing well. It might be that security's having that same place of, "How do we show that we're delivering value?" Because a lot of security work is dealing with risk, which is kind of if you wouldn't spend the money on security and there is no bridge, you probably saved the most things, so from that perspective. But you kind of have this nuanced discussion about how much security that you would bringing in versus how much money do you want to spend on it. And it's much more volatile or intangible than performance or stability is in that. So in that way, securities are different, I guess.

Matias Madou:

Yeah, and operations, you have a direct return. It's up and running and it works fast and it goes fast or it doesn't at all and your system is down. In security, it's way harder. If it's broken, well, there's an immediate problem, but if it's not broken, well, you don't know. Is it because of all the security measures that we have in place or is nobody using the system or trying to break into the system? You don't know. Essentially, what you initially said was, "Hey, you first had to level out the two groups between developers and operations." And once they are in balance, then you take another group with you and you have some free time where you say, "Hey, how can we take security into that balanced mix between developers, operations and security?" Is that correct?

Patrick Debois:

Yeah, at least that's been my journey over the years with these teams. New teams now in startups, they might start immediately thinking about DevOps and by usually they mean the pipeline. And doing the collaboration aspect in a smaller company is obviously easier than in a big company. And some might now consider, "Oh, we're going to start doing DevSecOps from the beginning because they have that value." But I think even if you're a small company, the balance is about, "Where do I put my resources?" And quite often in the beginning, it's not about ... Security is not that high on the level of priority because you kind of have to establish something first and you kind of take some risks, right?

Matias Madou:

Yeah, You have to have a business first.

Patrick Debois:

Yeah, yeah, yeah. And so, it's not on the top of the list. Obviously, you want to mitigate the biggest risks, but it's like building a house. If somebody tells you, "I want to secure your house." "Okay. Put everything in concrete and let nobody in." It's like, no. So we kind of need to take some risks and make that happen. But yeah, so that's usually when your startup becomes a little bit more value and you're delivering value, you're attracting more people, you're attracting potentially more risk of what you're doing. Then obviously, you need to worry about that part way more.

DevRel: What does it look like today?

‍

Matias Madou:

I would like to switch topics and I would like to go to DevRel because I think 20 years ago, it already existed with Microsoft doing a great job, for example, in building up communities and working with developers. I see more and more companies trying to figure out like, "Hey, how can we interact with developers?" And we have some DevRel position in there and seems that you're in that area too and trying to figure out like, "Hey, how can we better connect with developers?" So to you, what is DevRel and what are you doing on a day to day basis?

Patrick Debois:

Sure. I'm like six months in, so I don't know everything about DevRel.

Matias Madou:

It seems to be cutting edge and seems to be a lot of people want to go in that direction, so I'm very interested in hearing your perspective on how that's going.

Patrick Debois:

Yeah. So I think for me, from what I learned is that the ideal case is that DevRel helps you go in all the cracks that your company isn't handling. That's a very vague description, but let's say you're a developer and you go to a company's website and you don't exactly find what you're looking for. So how would you then do that? Create a ticket? That's kind of a high barrier, so you need to have a friendly person that you can just say, "Hey, I'm looking for this, or this isn't working, or how about I extend your product with this?" For me, it's a lot of listening and trying to help people. And maybe you bring them closer to engineering. Maybe you bring them closer to other parts of your company. They're like stewards for me that kind of help whoever circles run your company and tries to land them in the right area.

Patrick Debois:

That could be you create some useful tools around it so you can bring the value outside as well. So if it's not a core product engineering, you bring that value outside. You can also see it as a form of getting customer feedback back into your company, back to obviously potential customers. If you make them happy, that is another way and without bringing the strings of making it a commercial activity, just being helpful without any strings attached. Like I said before, it fits that role. I think in many companies, it balances a little bit between community and marketing or sales. From what I hear, the best ways to do it, if it stays away from hard sales quota and that it's more about helping people.

Patrick Debois:

It's a little bit more than a help desk, but it's more like how good you are at helping these people find their information or find the right people or help them with their problems. For me personally, the first months have been a little bit of a struggle trying to find my place. And then, I think we now settled on it doesn't have to be the developer that needs an immediate answer. Part of me is more guiding on a higher strategy but doing a similar role than you would do to the developers that are in the code all day, like what commander I need to type? I'm currently aiming to go where the DevRel is like, "Okay, I want to listen to all your problems on strategy, on process, and kind of see how I can help you in that perspective."

Patrick Debois:

It's a little bit different from the traditional DevRel which is very product focused on what we can do with the product to help you. I'm more focused on how can we help you with the concept or see the broader picture, so you kind of get a better feeling on where we fit in, how we might help you.

Matias Madou:

Interesting, so essentially where you have these big enterprises with the DevRel ... Well sometimes, companies feel untouchable. When you search companies, they're like, well, they're out there, they're doing their things, but with DevRel, the way I understand it is you're trying to bring that company down to developer speak or developer level where they can interact with you or they can talk to you, and they essentially have an entry point into that organization. And what you're doing is you're trying to make sure that you connect them with the right people in that organization so that they can gather the information that they want or influence the features that they have an interest in. Is that a little bit the synopsis of what you're trying to do?

Patrick Debois:

Yeah, and I think that it existed also a little bit, because you could see this in marketing, connecting people and finding the areas. But I think that DevRel is traditionally more tech-savvy and product savvy, in a way that they can give more direct answers for boots on the ground, like you say, in the developers working day to day like, "I'm hitting something, how can I help that person?" Instead of, "Okay, we're going to help you buy a product." It's a different vibe there.

Matias Madou:

Yeah, so if you already have the product, you already have a way in to that organization through tech support or customer success. There's definitely a way in, but essentially what you're doing is you're trying to find the next bunch of people that have an interest and maybe not slightly, or your solution, but not slightly that solution, a solution with a twist. And you're trying to find the groups of people that have an interest if we change X in our solution, we can actually go after an entire new market. You're trying to find an easy way to communicate with these people. Interesting, so how does security fit in there? Is there any angle where you say, "Hey, DevRel, security is important because XYZ," or is it irrelevant?

Patrick Debois:

I think it's currently helping because there's quite some appetite and some chaos in the field, in a way that's so if you're just connecting those people, it's quite rewarding at this time because we're still in an emerging state and that really helps build up connections and it might not build up a connection for me as a DevRel person, it might connect two other people that bring up a new idea like you say.

Patrick Debois:

I don't think it's specific for security, as say it's very helpful in emerging fields because you're connecting the current thinking. But even if in an established place, there's always something to help your company because if your company grows, there's people uncatered for, if you're not a customer, if you're not willing to sign up or like, who's going to listen to you? And that's kind of the community DevRel that still keeps one toe in their product company, but one toe in the community and what lives out there. Strategically, they might feed into product, so as security is currently in the emerging or DevSecOps is currently in the emerging field, makes sense to feed that information that we find back to the product as well.

Matias Madou:

So essentially, what you're seeing is developers with an interest in security, they're not the majority. We know that, so there's a minority of developers having a strong interest in security and DevRel is even more important for companies with security solutions to connect to with these developers and see what they think and how we can help them to spread that knowledge into their organization, spread the security knowledge in their organization.

Patrick Debois:

Yeah, because it's still emerging at this time. Yeah.

Matias Madou:

Last question, Patrick. I follow you a little bit on Twitter and seems that you have an interest in machine learning and robotics, or you just like fun videos on robotics and artificial intelligence. Do you have a keen interest or do you just like the fun videos of what robots can do and all the fun things you can do with AI and robots?

Patrick Debois:

I don't know which one you're referring to, but ...

Matias Madou:

I saw a couple of your Twitter where you're retweeting fun stuff with robots.

Patrick Debois:

I think there's a fascination from the looking at the interaction between technology and the people, so maybe that's why I'm retweeting that quite often, is that it reminds me sometimes how dumb they are, how smart they are, and ...

Matias Madou:

It was a smart one, by the way. It was the basketball one that you always score. So no matter how you throw the basketball at the ring, it always manage its ... The board always flips in the direction, so it always goes into the ring.

Patrick Debois:

Yeah. I remember that one. I think that, again, it's an example of ... In DevOps, there's continuously this debate, is it about a lot of tools because they get a lot of attention and the human, and more and more start just to believe that there are technologies amplifying the humans and that was a good example. If you want to make something happen, technology will help us and technology can be used for good and for bad. Yesterday, I ranted about all the algorithms that go against me, all the sites like Spotify, not giving me the music I want, Google limiting my search, Twitter messing up my timeline, Netflix not showing the movies I really want. Even with all the AI and kind of whatever thing, something never beats the human in that but if you can get better with technology, that's good but there's also a downside.

The more we do automatically ... I know nothing about a car and I have to go over to a garage and that's because everything has been abstracted the way and I can't deal with a failure. I have to call somebody for that. And that's the downside, so the more we automate, something called the irony of automation, is that the less good at something you get, which means you have to practice again, which means you're doing the same thing again, so it's kind of an interesting circle that we find ourselves in.

Matias Madou:

That's true. That's true. Patrick, thank you very, very much for accepting to being the 11th guru on the Software Security Gurus Webcast. It was a great chat. Thank you very much

Patrick Debois:

And as we're both from Belgium, I'm going to say it in Dutch.