Making Security More Inclusive With Francois Raynaud

Francois Raynaud: "Security has always been about exclusion, which is the need-to-know security clearance. Now, DevOps and development is more about the inclusion. You have to align the activity in the security space with the needs of the business and how it operates. People are talking about the shortage of security people, but actually, what is lacking is security people willing to be transparent and give away their knowledge. Security's job needs to become much, much more of a mentor and a guide. If we want to make security and dev, and the overall security area better, we need to promote this inclusion."

[INTRODUCTION]

[0:00:36] Guy Podjarny: Hi, I'm Guy Podjarny, CEO and Co-Founder of Snyk. You're listening to The Secure Developer, a podcast about security for developers covering security tools and practices you can and should adopt into your development workflow.

The Secure Developer is brought to you by Heavybit, a program dedicated to helping startups take their developer products to market. For more information, visit heavybit.com. If you're interested in being a guest on this show, or if you would like to suggest a topic for us to discuss, find us on Twitter, @thesecuredev.

[INTERVIEW]

[0:01:07] Guy Podjarny: Hello, everybody and welcome back to The Secure Developer. Today, we have with us Francois Raynaud. Welcome to the show, Francois.

[0:01:13] Francois Raynaud: Thank you very much for having me.

[0:01:15] Guy Podjarny: Before we deep dive, can I ask you, Francois, just to explain a little bit about what is it that you do in the world of security, and how you get into it in the first place?

[0:01:23] Francois Raynaud: Okay. I started working in security 17 years ago. Done all different kinds of work. Started as a pen tester, incident response, a great emphasis on building security operating centres and consultancy. I spent about, I don't know, eight years in Verizon, which was a really good company to learn from. Learned a lot from a network security point of view, which led me to become a security architect, which I am now dealing with a global online retailer, which comes with its own problems as well.

[0:01:51] Guy Podjarny: Cool. When you say you're a security architect, you consult companies in that space or you work with a specific one?

[0:01:56] Francois Raynaud: I consult companies, so I've got different customers. All my consultancy is based on SABSA. The idea behind SABSA is using open source and the inclusion of security within the business. There is nothing worse than having technical controls which are in place who haven't got a direct lineage to your business requirements. That's what we tried to do as security architect, is just go back to basics and make sure companies are implementing the right controls without too much or too less, as it is most of the time.

[0:02:25] Guy Podjarny: Yeah, that makes sense. Basically, you have to align the activity in the security space with the needs of the business and how it operates. Otherwise, it will never really catch or connect correctly.

[0:02:34] Francois Raynaud: Yes, definitely. It's always been the hardship of security people, which is like, show me what is the ROI on your security product? I can't tell you what's the ROI, but I can tell you what is going to happen if you don't actually implement those ones. A CFO is always going to ask you, "Give me a price, give me a value. Can you cost me an incident?" It's just about, every incident is impossible to actually cost. You've got some great mathematical formulas, you've got some white papers everywhere, but nobody ever been able to actually tell you from the start, "I need to put that amount of incident response within our company to protect and to arrive to a certain ROI." That's the main issue we've got.

[0:03:13] Guy Podjarny: Yes, it's basically easy to make up a formula. But between that, and that formula being accurate. That's a whole different story.

[0:03:19] Francois Raynaud: Yes, basically it's like for your budget, just get a realistic number, and just add another zero to it, it's going to be cut off at the end, so don't.

[0:03:26] Guy Podjarny: Yes, precisely. Cool. Okay. Well, it sounds like you sort of jump around and work with a lot of these different companies to set up security architecture, consulting, and kind of working with them closely. Alongside that, the way you and I got to meet was as part of an event that you organised called DevSecCon. Do you want to tell us a little bit about that one?

[0:03:42] Francois Raynaud: Yes, that's correct. DevSecCon, which stands for Development Security Conference. The premise of DevSecCon was to promote inclusion. Security from the beginning has been promoted exclusion, which has been need-to-know basis, your security clearance, don't talk to this person about it, don't tell them that, et cetera, et cetera. Don't tell them what the actual problem is. We're doing this investigation, that needs to be all hush-hush. But at the same time, if you're actually being inclusive towards the developers to your business, you understand what the business wants to do, what does the developer want to do, and how we can help them achieve this in a secure manner.

The aim of it was to demystify security, and get everybody in the room, have a good time. So far that works, so that's the third edition of what we're doing. DevSecCon is basically myself, my wife. Luckily, my wife is a graphic designer, so she's doing all the design.

[0:04:35] Guy Podjarny: Yes, that explains a lot of things.

[0:04:36] Francois Raynaud: That's why it looks so good.

[0:04:38] Guy Podjarny: Correct.

[0:04:39] Francois Raynaud: Yes. I just do the content, I do all the promotion, and also business side of it. That's how we came to meet. The aim was to bring people like you, which understand the problem, and actually want to work with development teams. There's nothing more frustrating than security trying to fix a problem in isolation without understanding the tools, which are being used by the development, DevOps, and how they can benefit us.

If you take, for example, DevOps, OCR java methodology, OC activity processing, et cetera, et cetera. This is really beneficial for security. Security used to be, well, if you go back to PCI DSS 1.0, which is, you need to have a firewall somewhere. It didn't even tell you need to have powers for the firewall. The dev guys will have understood that. They will tell you that, "Yes, you've got your firewall on the side, you need to put some power in it."

From a security point of view, we've been really good. We just defended ourselves using compliancy, and just say, "Guys, you need to be compliant, you need to do have all these things in place." Without understanding what does the business want to achieve. That's one of the first question I always ask, which is, "What are you trying to achieve?" The other way to look at it is, people will ask you, "Oh, that doesn't match my risk appetite." You're just like, "Okay. Well, define your risk appetite. Do you want to lose one record, two records, 10 records? Does it matter? Does your customer data matter at all?"

That's what we've been trying to do, is explain how security impacts the rest of the business, how many companies are just going completely under. If you look at Codespace, for example, which was a training company, all hosted on AWS. Perfect from a DevOps point of view that was really clever. Unfortunately, they left all the encryption keys on to the public bucket of the S3. Somebody came in, they deleted everything, deleted the backups, all the backups. The company went bust. That's a perfect example of just how we need to work together.

Security is not a blackout, really. There's just a bunch of guys that just grow some beards, grow their hair long, and actually, trying to do something better. But it's time for us to come out of the dark rooms that we've been building around each other, and explain what we're doing, explain how we find things explain, how security can benefit a company.

[0:06:48] Guy Podjarny: Yes, and I guess kind of learning the process. There's a lot in what you said that I'd love to unpack. I definitely relate, first of all, to the cultural aspect of it. I worked in the field of security for about 13,14 years. Then, I spent six years in the world of performance. The delta between just the attitude, and embracing the community, and working with others versus against others. Both the people that are a part of your community, and the people that are around your community was night and day. That wasn't actually one of the question marks I had in my mind when I was wondering whether I want to get back to security.

I feel like events like DevSecCon, which are still few and far between. And hopefully we'll have more and more of those help bring some of that more positive attitude, the one that is inclusive, that is – both embraces the other entities for the purpose of teaching them, but making security everybody's job and everybody's responsibility, but also everybody's understanding, so you're not just following instructions, you understand, and you know why it matters and how to do it.

But also, the other way around, I love some of those comments you made around learning from developers. There's a decent amount of ego in the world of security. There's no shortage of ego in the world of DevOps and dev. But I think, those worlds tend to be much more open for criticism, for constructive criticism than may be some of the behaviours we see entrenched in the security space. It'll be good to kind of put that off to the side, and embrace some of the methodologies, both because it'll make security better, but also, because there's really no other way. It's the only way to sort of keep security sustainable.

[0:08:19] Francois Raynaud: Definitely. Another part of the work that I do is advise on products for certain companies. I can't divulge them, unfortunately. But the aim is just making them understand how they can build security in for the customers. Those companies are DevOps companies. I don't need to explain the name, but they're sort of a deployment mechanism. They've got the ability to actually capture all the data, that from a security point of view is really beneficial. From a DevOps, as the same time is really beneficial. You're just making them work together, is just opening the book and being more transparent.

Security has been great, as in without the security policy, which almost 500 pages document, and everybody has it printed on the desk. The only reason we had it printed, that's just basically to bash people around the head with it, which is not really beneficial. It's just like, let's build it together. Let's actually transform the security policy as code. There's just – the developers will understand that I don't need to hide anything, which is in security policy. You need to bake it in your security product from the beginning.

If you want to fix the security problem or implement security later on, that's going to cost you a fortune. If you just build it part of your requirements, your job is done. Not completely, you need to make sure that it gets actually printed.

[0:09:36] Guy Podjarny: Of course, but the cost is dramatically different. I guess, the other beauty of that statement is, you can swap security for many other aspects of software quality, and that statement would hold, so it's something that should be – people should be able to relate to.

[0:09:49] Francois Raynaud: Agreed. Totally agreed. Speaking to a security vendor the other day, and they were just, "Oh, I've got this new technology, does the silver bullets." It's just like, "No, it's not." "How is it?" "How do you anticipate your customers need? How do you know their financial data? How do you know the flows, the data flows, what regulation, et cetera, et cetera." The tool is good, but it's just a tool. You can actually build tools. I can't build tools. That's why I rely on people like you to actually just make this conference great and make the security better.

But, it's just simple ideas, which is from an incident response point of view. I need data, all the data. I need to know everything in order to be able to understand how did this incident, how did this attack actually occur? How can I prevent it? If you look at incident response, everybody's talking about those five steps you identified, to the point you remediate, et cetera. But the sixth step is really important, it's key, which is lessons learned. What did I learn, and how can I ensure that it's not going to repeat itself?

Don't just publicise for yourself a security, you're, "Oh, wow, I've just given them a really good root cause analysis report to my CSO." It doesn't help him. The person who will benefit from it is going to be the developer, which is, change your application, change your processes, change your performance monitoring, change your monitoring to actually just get this feedback loop as quickly as possible.

People are talking about the shortage of security people. But actually, what is lacking is security people willing to be transparent and give away their knowledge. There is nothing special about security, is just the only thing we've done is read a book, or plenty of them. Some of us actually written some books, which is really good, which is a way to actually promote this inclusion, where – as we're talking a bit earlier, which is security has always been about exclusion, which is the need to know, security clearance. Now, DevOps and development is more about the inclusion, which is how can we work together? How can I make you build a better secure product from the start?

[0:11:48] Guy Podjarny: In this event, like these all resonate with me very, very much. How do you look at the two different audiences? You're talking about developer and security, DevSecCon. Inevitably, you're probably pulling in some people from the security space that want to broaden their ability to reach out to, and better understand, and better interact with dev. I think that's maybe the given, that's probably the starting point here. Because security people really have no choice here. You live in this world, there are developers around you, they will create software in their new and modern ways. You sort of need to accept that. How much did you see sort of uptake from the dev side coming into DevSecCon, how much does that play a role, and how do you see that progressing forward?

[0:12:30] Francois Raynaud: The first DevSecCon I was working at the time was really good DevOps team into a gambling company, believe it or not. I was really blessed by the ability to communicate, identify a problem, and the willingness to fix it as quickly as possible. Security will put it on the backlog, and put it on register, it's in a risk register. It's in a risk register, it's fine. Who's looking at the risk register? Nobody.

[0:12:57] Guy Podjarny: Yes, ever.

[0:12:58] Francois Raynaud: Because you haven't got a risk officer, which is actually just driving this thing. The first DevSecCon, we had really a 50% DevOps, 50% security. But the common denominator was operations. What we realised is just, we've done a show of hands, we're just like, "DevOps, half of it. Security, half of it." Operation, also, hands were up. That's the main problem we were trying to fix, which is from an operational point of view, how we can work together.

The point of security, or my point of security is that, from the inception in your pipeline to your delivery, it's not that it shouldn't be zero defect. Defects are going to be found. Security people have got enough time on the hand during the night to actually find some new vulnerabilities. What is important is the zero variation from your immutable object to your product. That's what we're looking for, which is like, how can I measure there? I've got a consistent product without adding new functionality part of it, where I shouldn't be looking for defects. Defects are going to be found somehow. There's going to be people, you, me, which are going to be looking at, can I exploit this function? That's the main issue.

I think, DevOps is now embracing security. We've got to be thankful for Gene Kim to actually just started this trend. But. one of the things that I think was lacking in the last book was more emphasis, and now emphasis on security, which is how can we work together. It's not hard, really. Especially a person like this, they used to be one of the founders of Tripwire, totally understood from the beginning, which is security people need this data. From a DevOps, I've got this data, so let's exchange this data. It's pure and simple. It's just about inclusion.

[0:14:40] Guy Podjarny: Yes. I definitely kind of like Gene Kim's work. There's a quote from him or from Josh Corman, I keep mixing it up. Talking about how to fix security, you have to leave security. There's a lot of ways to interpret that statement, but it includes expanding security outside of security, but it includes you as a security person, leaving security for a moment, seeing some other things. I think I relate to it, just having done that a little bit, having sort of spent these years, and in the world of perf. There's a lot to bring in.

I'd like to maybe drill a little bit more, like you mentioned, a few things here. One is this notion of DevOps versus SecOps. You mentioned SecOps for your job description earlier on. Also now, talking about how the audience is all operations and working together. A little bit about the evolution of which path is the right one or how would you put the emphasis. Do you think the bulk of the work right now as an industry is around getting the DevOps teams, the dev, the ops teams to embrace some of these security responsibilities and do them? Or do you think the bigger opportunity is actually to get security to open up to do that type of sort of education and outreach? That, the ground is already kind of ripe for absorbing that information. It's more about getting it out there.

[0:15:55] Francois Raynaud: It's funny. I've got two different customers, which I've taken two completely different approaches on this. One of them, they actually just disbanded your security team, with the hope that DevOps will be able to learn security, as written on the back of a fact packet. Good luck. That's not really going to work. But like all the times, you just need to wait for an incident for things to get corrected. One way to do it is actually – so, DevOps is here to stay. Security was here to stay. But I think, there is a way where we can change the attitude of security and go to a devolved model, where we embedding security part of every function.

As a security architect, I work mostly with all the enterprise architect, which are not security-related. But it's about me inputting everything security-related within the enterprise architecture, to help the product, the company develop and be secure. What security needs to change is this attitude. Security has been the echo chamber of security. We just love talking to each other and just say, "Hey, look at this new tool. I can break everything." It's like, "Can you fix it?" "Not really." But that's not the problem. Then, you end up into your responsible disclosure, et cetera. Which, in my opinion, is really important. You need to disclose responsibly every security issue that you found. Even more, you need to work with all your DevOps and all your developers to actually fix it from the start.

It's not hard to actually talk with people, it's not hard to actually identify what is the security debt that you're carrying all the time. The pen tester, typical pen testers will arrive, identify a bunch of vulnerabilities, then go back home. Been there, done that. It's fantastic. You haven't got to fix it. Then, slowly, slowly, they ask you, "But what is the fix? What is the remediation?" We point them out to an RFC, like totally obscure numbers. Read this RFC, it's all written and explained in there. That doesn't work. It's all about translating those security problems into the world of DevOps, the world of developers, which is, I need to learn every day about developers. I need to learn their new technology, doing your talk on DevSecCon.

Actually, to Google quite a few of the words because which is like, "Well, I didn't know. I stop with C++." That thing, security has been used by the rest of the business as the people monitoring for things that can be fixed, or that people don't want to be fixed. We're going to call that a security debt. Coming from a SecOps, which is security operations. We were used to create intrusion detection rules to actually monitor for those vulnerabilities that nobody wanted to fix. You've got to deal with the security debt, because, yes, you're going to write it on your risk register, you're going to encrypt your risk register. And suddenly, this employee actually left, and maybe, you were not really nice when you gave him the last check, and redundancy was not enough. He's going to come back and he's got this data. He knows that, two years, three years down the line, you still haven't fixed these vulnerabilities.

It's not going to take a lot for this person to actually go and publicise it. Treat them well, make them work together. From a security point of view, you've got to use all the tools that developers are using. You've got to use the backlog ability. Now, when I identify vulnerabilities, I actually directly input them into their backlog. That could be Rally, or that could be any type of backtrack that you're using.

You're actually using the tool, and you can actually predict your security posture of how it's going to be in three, four, five weeks. But, of course, if everybody's respecting the process, but that's all down to that. Security is not hard, it's about understanding your processes, understanding your requirements, and implementing them securely.

[0:19:36] Guy Podjarny: As a part of the existing processes.

[0:19:38] Francois Raynaud: Yes. I think I agree. I do feel like in my mind, there is a little bit of a bias around, maybe where the biggest gap is, but you need the two to play together. Security, and I think this is also what you're saying is, like security's job needs to become much, much more of a mentor, and a guide, or you need to be doing things. But you almost shouldn't have dedicated security-related tools in the company. You almost want all of those tools to be now a part of the existing stack, if they could be serving a security purpose that that should have. But they shouldn't be exclusively used by the security team for the majority of the cases, because you actually want them embraced and used by the rest of the team. Then, you want security to be sharing and exposing the work that is done with the rest of the organisation.

[0:20:24] Francois Raynaud: Definitely. One of the best achievements was actually just to relinquish ownership of security tooling within the security team. Actually, give it to the DevOps, which – yes, you can run on my vulnerability management scanners, you can run all this because you're the one that's actually looking for the feedback of those. I'm not, "Yes, I'm going to be able to tell you." That's bad. That's actually really bad. But you're the one who's going to fix it.

My role as security professional is to teach you how to decipher those security coding words that we put in place. To do the same, about being French had to learn English. Now, we wouldn't be able to give you a technical conversation in French. Security people ended up into this inability to explain what they're doing by creating those buzzwords, and people don't understand it. You arrive, now, we're trying to make it sexy. We just poodle, et cetera, et cetera. But if you actually analyse what it means. nobody understands it at all.

[0:21:19] Guy Podjarny: Yes. I think all this conversation kind of goes back and explains what the role of the security professional, or the dev or DevOps person needs to be in the space. Maybe let's sort of backtrack and talk specifically around the activities in the community, and sort of back to DevSecCon, and just some of the work that you're doing with OWASP. If I'm in one of those spaces, I'm a security person that wants to sort of get more engaged with dev or the other way around. What's coming up from DevSecCon from all aspect that I can get involved with?

[0:21:51] Francois Raynaud: It's quite funny. DevSecCon is the only conference which is actually looking at this inclusion of security and DevOps. If you want to be part of the change, that's the place to be. You've done it last year as a presenter, and that's really good, which is just really just giving away your knowledge. What we're doing is, we've been able to keep the prices really low to make it affordable to everybody to come. The aim is not a money-making machine. The aim is providing as much education as what we can. We started in London, personal reason that I'm moving to Singapore. What we're doing, we're actually creating DevSecCon Asia. I've got two partners over there, which are working on this.

At the moment, we're going to be looking at two events a year. One in London, one in Singapore, working with different colleagues on DevSecOps community to actually bring up another event in California. You might say that what I'm trying to do here is to do an endless summer, and you're going to be perfectly right.

[0:22:46] Guy Podjarny: That's not a bad role.

[0:22:47] Francois Raynaud: No. No. Well, I spent 15 years in the UK, and looking for a bit of sun. Now, it's just completely white, starting to be transparent. But we're doing those events, so it's going to be three, four years, and try to make it as local as possible, so everybody can access.

The other work that we're doing. So, I'm really lucky to be working with OWASP, which are really good. What we're trying to do, what we brought up is what is called the OWASP Summit. The OWASP Summit occurred in 2008, 2011. This is five days of interactive work. It's not a conference by itself. It's basically, we're spending five days in the villa, but there will be plenty of villas, because there will be about 150 of us. This year, we're doing it in Central Park, actually, just outside of London. That's from the 12th to the 16th of June. It's five days of just inclusive working on workshops. We've got about 10, 12 different kinds of topics. You coming here to actually give your knowledge away.

Type of things we're going to be looking at is going to be responsible disclosure, threat modelling, but also Lambda security. Redoing all the OWASP cheat sheets, doing a bit of cleanup on the type of project that OWASP has been doing. OWASP is a really great community. Without them, I don't think security would be where we are at the moment.

What we need to do now is, instead of this one person talking to everybody, and everybody listening like we've all done at school, is just, let's all talk together. We bring in all the best people from all around the world, and we're putting them in a room. There's going to be some food, there's going to be some drinks, there's going to be little sleep, but there's going to be lots of really good information, lots of resources, which we're going to make available to everybody for free.

[0:24:28] Guy Podjarny: That sounds great. I think, to an extent, that's also again, a page out of the DevOps world because DevOps is also a few too many men versus women that sort of let their beards grow, and sort of see how that evolves. But I think, a lot of good practices came out of that and this type of anywhere from sort of summits, to unconference, to sort of collaborative work, and outputs. It's definitely a key there, and a good evolution for OWASP.

[0:24:51] Francois Raynaud: Definitely. If you look at Amazon reinvent so it started it was really good. But if you go to it now, basically, Amazon inviting some people to talk about Amazon. You couldn't be more narcissistic, non-realistic, as you will say in French. It was just like, it's really this person looking at themselves. That's what security used to be. DEF CON, Blackhat have done it, and it's just been fantastic. Just love five days, lots of fun, especially in Vegas. But did we teach anything to anybody? Not really. The only thing we taught them is just about, be careful because your card is going to get hacked. It's just, "Oh, brilliant. What is the solution?" "Well, we haven't got one. We didn't think about that." That's not what we're getting paid for.

The DevOps guys are doing things differently. 'm trying not to mention the companies here. But some of them, which are part of this continuous delivery, they are providing more open-source connectors than any other companies are doing. Sometimes, you actually wondering, where do you make your money? How does it work? But they're giving to the community.

A good person I'm working with, [inaudible 0:25:58] has been coming to talk at DevSecCon, and he's been really explaining just, "Look, guys. Security, you've got to be transparent." He made it really clear, as security, please come and talk to me. I can build the tools for you. Because security is not necessarily there to build the tool to make things better. We're just here to break things, which that's got to change. We've got to really look at the problem in a different manner. Because if we didn't have compliancy, and all those different regulations, I don't think security industry will still be here today. We kind of failed. The premise of DevSecCon was to completely change this, was to give the information to people so you can work together. Ideally, I will make myself redundant, because I've taught so much to DevOps, and that happened with a different company.

[0:26:46] Guy Podjarny: Yes. I think we also know that sort of in this world, that's never entirely going to happen. But what might happen is, instead of trying to address this ridiculous talent shortage we have right now in security, which is a shortage because we assume a certain sort of distribution of work, which would be different. Now, I'm not saying, redistributed the wealth here, but I am saying, redistribute work, and ensure that just more and more of the security knowledge and the security activity gets disseminated to be a part of sort of built-in application. The remaining still very large amount of security guidance, security analysis, security understanding, it's probably still going to remain in the hands of experts. But definitely, the ops part of it, for DevOps, the SecOps needs to be a part of the regular ongoing, and the consideration of it needs to be sort of embedded in their reaction.

[0:27:32] Francois Raynaud: Yes. From a SecOps point of view, as you were touching on is, the only thing you're doing is like DevOps, you're responding to an incident. The incident might be a server that came down, but in that case, that's an attack. Okay. The first analysis can be done by DevOps. How you gather this data, what data are you looking for, you just need to tell your DevOps what they need to capture. Then, okay, maybe you've got a forensic investigator. That's a speciality. But is it really security-related? Not really, because it's –

[0:28:01] Guy Podjarny: It's analysis.

[0:28:01] Francois Raynaud: Exactly. It's analysis, and anybody can do it. I've done it. I'm sure everybody can do it.

[0:28:08] Guy Podjarny: Cool. Well, I think this was a really interesting conversation. We talked about the role of security operations versus ops as a whole or sort of DevOps, and how those are, in many ways, sort of two sides of the same cone. We talked about DevSecCon, and the upcoming OWASP events, and all of these great spaces. That hopefully will help all of the people listening to this participate, and kind of play a role here, and help contribute some of their security knowledge or development knowledge to be a part of this ecosystem. I think, also, some interesting observations around the role of the security person as a mentor versus an operator, if you will, or as a, how does that work, as a food for thought.

I guess, before we part, can I just ask you a question that I ask every guest on this show. If you're talking to a dev team that is looking to sort of uplevel in terms of their security posture, what's your sort of recurrent pet peeve? What's the sort of the one practice you recommend they look into to get better at the space?

[0:29:02] Francois Raynaud: Sit down together with security, and that's the same thing, security needs to sit down with DevOps. We both got to learn something from each other. That's one of the first thing I'll do, is I'll bring those two teams together, and make them sit together. Go and have a drink, go outside. party, just go and have some dinners together. Understand what the other side wants and understand what you can bring to them. I think it works both ways too. If we want to make security, and dev, and the overall security area better, we need to promote this inclusion.

[0:29:36] Guy Podjarny: Yes, I think that's really good advice. Again, kind of has demonstrated to work in the DevOps world. Break down the barrier. Fundamentally, it starts with people.

[0:29:44] Francois Raynaud: Exactly.

[0:29:45] Guy Podjarny: Perfect. Well, thanks a lot, Francois, for coming on the show.

[0:29:48] Francois Raynaud: Thank you very much.

[0:29:49] Guy Podjarny: I hope you enjoy the show and tune in for the next one.

[OUTRO]

[0:29:53] ANNOUNCER: That's all we have time for today. If you'd like to come on as a guest on this show, or want us to cover a specific topic, find us on Twitter, @thesecuredev. To learn more about Heavybit, browse to heavybit.com. You can find this podcast and many other great ones, as well as over 100 videos about building developer tooling companies, given by top experts in the field.