---
title: "Aviat Jean-Baptiste — The AppSec report"
url: https://appsecpodcast.com/aviat-jean-baptiste-the-appsec-report/
date: 2020-10-13
duration_seconds: 1958
guests: ["Aviat Jean-Baptiste"]
topics: ["Vulnerabilities and Exploits"]
audio: https://www.buzzsprout.com/1730684/episodes/8122587-aviat-jean-baptiste-the-appsec-report.mp3
video: https://www.youtube.com/watch?v=hv2KwtrL-Wk
transcript: true
---

# Aviat Jean-Baptiste — The AppSec report

*October 13, 2020 · 33 min*

with [Aviat Jean-Baptiste](https://appsecpodcast.com/guests/aviat-jean-baptiste/)

on [Vulnerabilities and Exploits](https://appsecpodcast.com/topics/vulnerabilities/)

[Audio](https://www.buzzsprout.com/1730684/episodes/8122587-aviat-jean-baptiste-the-appsec-report.mp3) · [Video](https://www.youtube.com/watch?v=hv2KwtrL-Wk)

## Show notes

Jb Aviat is CTO and co-founder at Sqreen. Prior to this, Jb worked at Apple as a reverse engineer, pentester and developer. Jb joins us to discuss the new Application Security Report that Sqreen has released. We review what the report contains, key takeaways and conclusions, and even consider which framework/language is the most secure. We hope you enjoy this conversation with.... JB Eviat is CTO and co-founder at Screen. You cannot hack yourself secure. Everyone wants to focus on the offensive side of the equation. The challenge is that developers get bored with hacking broken pieces of code after a while. Sure, it's a shiny, cool new thing in the beginning, but how about one year later?

The Application Security Podcast is brought to you by [Security Journey](https://www.securityjourney.com/).

About Security Journey  
JB Eviat is CTO and co-founder at Screen.  
→ [Learn more about Security Journey](https://www.securityjourney.com/)

Connect with Aviat Jean-Baptiste:  
→ [Sqreen (now Datadog AAP)](https://docs.datadoghq.com/security/application_security/)  
→ [OWASP Top 10](https://owasp.org/www-project-top-ten/)

Mentioned in this episode:  
→ [Sqreen (now Datadog AAP)](https://docs.datadoghq.com/security/application_security/)  
→ [OWASP Top 10](https://owasp.org/www-project-top-ten/)  
→ [HackerOne 2020 Hacker Report](https://www.hackerone.com/press-release/hacking-career-soars-popularity-according-hackerones-2020-hacker-report)  
→ [Ruby on Rails](https://rubyonrails.org/)  
→ [Symfony](https://symfony.com/)  
→ [Laravel](https://laravel.com/)  
→ [WordPress](https://wordpress.org/)  
→ [Express](https://expressjs.com/)  
→ [MongoDB](https://www.mongodb.com/)  
→ [Node.js](https://nodejs.org/)

Chapters:  
00:00 Meet Aviat Jean-Baptiste: Aviat Jean-Baptiste — The AppSec report  
01:34 We're going to talk today about a new report that has  
04:38 Now I'm curious. It sounds like you came from a lot  
10:52 Yeah. So, JP, that's what we're here for, is a report  
13:00 So understanding a little bit more about what the report is  
15:34 If we think about this from our audience's perspective, What would  
19:18 With that in mind, and let's take— I know you give  
21:30 We did talk about, we've already kind of mentioned a few  
24:45 That's a great point about use of frameworks and making sure  
27:47 As somebody who spends a good amount of time in Ruby

## Transcript

*4,928 words · assemblyai*

**0:00 Chris Romeo:** JB Eviat is CTO and co-founder at Screen. Prior to this, JB worked at Apple as a reverse engineer, pen tester, and developer. JB joins us to discuss the new application security report that Screen has released. We review what the report contains, key takeaways and conclusions, and we even consider which framework language is the most secure according to the data in the report. We hope you enjoy this conversation with—

**0:25 Robert Hurlbut:** JB Eviat. JB Aviat.

**0:27 Chris Romeo:** You cannot hack yourself secure. Everyone wants to focus on the offensive side of the equation. The challenge is that developers get bored with hacking broken pieces of code after a while. Sure, it's a shiny, cool new thing in the beginning, but how about one year later? At Security Journey, we focus on long-term sustainable security culture with the developers as defenders. Our approach integrates experimentation together with learning. We believe that developers need hands-on experience but not at the expense of fundamental knowledge. Visit www.securityjourney.com to sign up for a free trial of the Security Dojo or schedule a demo. Hey folks, welcome to this episode of the Application Security Podcast. This is Chris Romeo, CEO of Security Journey and co-host of the podcast. I'm also joined by Robert. Hey, Robert.

**1:30 Robert Hurlbut:** Hey, Chris. Yeah, Robert Hurlbut here, Threat Modeling Architect.

**1:34 Chris Romeo:** So we're going to talk today about a new report that has come out upon the world of application security, and today we're joined by JB from Screen, where he is the CTO. JB, we always jump right in for our listeners with the question about your security origin story. Because what we found is our listeners, they want to know where everybody comes from. They want to hear this story. So if you could share with us, how did you get into the world of application security?

**2:06 Aviat Jean-Baptiste:** Hello folks. Good question. So I've been passionate about IT security since I'm like a teenager. And every time I had a chance to build a project or something at school, it was always related to IT security. I did a lot of mathematical studies, so I did a lot of things on RSA factorization, prime numbers, etc. And when I reached engineering school, my first internship was done with a pentester team. So that was like a deep dive into the professional world of security. It was like most of the days wearing shorts and t-shirts the office hacking stuff, and some of the days with a suit and a tie and going to some customers to actually see with them how we could help them. So I've been really hooked into the field of security, big fan of the technical aspect, computers, how can you design and build secure systems, and how can you break them on the other hand. And so So that was really, really my passion. I started my first job as a pentester in a consulting firm, smallish, 40 person, but very, very great technical level. Here, I built a lot of offensive tools. And after a while, I've been hired at Apple where I met Pierre, my co-founder at Screen. And so that's where the things that I was doing with passion became even stronger, surrounded by an amazing team of really, really deep people. And so, we turned much more into reverse engineering and attacking systems that were pretty elaborate. And so, we spent, I spent 5 years helping developers build and design better systems. And so, that was our, really our time at Apple. once this was done because we decided to automate and to put much more intelligence into what we were doing from a technical standpoint. And so we decided to start a company together to build application security in a much simpler way. And so we started Screen.

**4:37 Chris Romeo:** So now I'm curious. It sounds like you came from a lot of kind of the offensive side. And now Screen is focused more on the defensive side. What was your kind of motivation to make that change from offense to defense?

**4:54 Aviat Jean-Baptiste:** Yeah, so it was very progressive. I think many people are attracted by the field of security because of the offensive side of it. It's so fun and sometimes so easy to break defenses, to break into things and to steal data, or to prove that you managed to take over something. And so, as I think as a teenager, teenager, I love to play, I love games, and so that was really, really appealing to me. And as you grow up, you look for different challenges. And one of the challenges that I really discovered while I was at Apple is that, yes, I was still doing offensive security, building, breaking systems, but we were also working hand in hand with developers and helping them, advising them to build much better software. And that's how we— I discovered that building secure systems was actually extremely hard and much harder than I ever thought, and that the tools and the processes and all the methods that were available were far from perfect. And so we understood that the best product you could dream of in the security industry was not here, and that many, many things were done with ideas that were pretty ancient, that the space of security was still pretty secretive, you know, the, the, you won't try my product until you sign an NDA and things like that. And so that's how we realized that actually all this culture and this mindset of the, of the old security days that is still present in many places today still exists and is not helping because it It's not good to bring awareness, to bring trust towards a given product or techniques. And so that's one of the things we wanted to change. And so that's how I think I moved from the offensive side into the defensive side. But I would also argue that if you want to build a security product, you have to know, at least for the technical aspect of it, how attackers work and how the offensive people think. Otherwise, it will be pretty hard to build something Yeah, I think you've got a good combination there.

**7:19 Chris Romeo:** And it's funny you mentioned building a security product. In my past career working in big companies, some of the most difficult product teams to influence for security were those that were building security products because they had this mindset or this idea to say, well, we're building a security product.

**7:39 Robert Hurlbut:** Right.

**7:41 Chris Romeo:** And we kept saying, well, that doesn't actually mean you're secure. That just means you're building a security product. Like, you still have to follow the same things, the same best practices of secure coding and threat modeling and running static analysis tools and dynamic tools and all the things that go into building a solid security architecture.

**8:01 Robert Hurlbut:** Right.

**8:02 Chris Romeo:** Just because it's a security product doesn't give you a pass to say, well, we're building a firewall. Well, great. It's going to be an insecure firewall if you don't do the right things.

**8:11 Aviat Jean-Baptiste:** Absolutely. And I think that's a bias of many security products. But as— so Pierre and I, as co-founders, we are both security nerds. And so if you, if you do things, uh, just with your guts when you start the company, you will hire people that you know, that you trust, people in your networks who are security experts, right? But the security experts are not the best engineers, architects, software, principal engineers, people that are able to forecast technology trends, et cetera. The security crowd is not used to build products that will scale, that will be secure, that will be safe, and that have all those different things into account. And so one of the first things we did at the beginning was say, okay, let's not look for that. And so we hired our first engineer that was not at all a security expert, was an excellent engineer. So the security bits was very, very close from him and he learned very, very quickly. But I'm proud to say that, yes, we managed to start the company with non-security experts beside the 2 founders.

**9:19 Chris Romeo:** Okay. And I think this is really, really important in the DNA of the company because it helps you build a company that is not super secretive, that doesn't have like the former dark security Yeah, that's, you know, the same principle that we've applied in building Security Journey is we're a security-first company, which I think I would say the same thing about Screen, you know, from what I know about Screen and how you operate. And so, it's great, and you may have the same experience, but from time to time, we'll have a new customer who will send us a set of questions, security assessment questions to fill out, and they always love it when they get back our answers because there's usually no follow-up questions. Right.

**10:07 Aviat Jean-Baptiste:** Yeah.

**10:08 Chris Romeo:** Because we've built from a security architecture perspective, like, we're thinking security first. I understand why they ask a lot of these questions, but it's the perspective of saying, well, we've actually built to best take care of these things right from the beginning. We built it from the ground up. And so, that always blows people's minds. But I know we're not here to talk about building a security product, but we'll have to have that as a follow-up conversation for the future because I'd love to just pull that thread for a full hour of talking about, you know, building a security product and what goes into it, but we'll add that to the backlog. So, Robert, I know you were gonna take us into kind of a discussion about the report that Screen has put together.

**10:52 Robert Hurlbut:** Yeah. So, JP, that's what we're here for, is a report that your company put together. Can you tell us what that report is just so we have that context?

**11:01 Aviat Jean-Baptiste:** Yes, absolutely. So, This report is the state of all the vulnerability exploitations that were detected amongst our customers in the past year. So maybe I need to give a bit more context about what is this data and where it's coming from. So our product is basically a RASP, right? So we install in our customers' servers and Within there, we monitor their runtime, and so we are able to check each time a dangerous call is performed if this call is actually a vulnerability exploitation or not, right? So we have very little false positives because we use what we call semantic-based analysis, which means, for instance, to detect a SQL injection, we would parse the SQL payload and check if the user parameters provided by the frameworks are present in that SQL query. If they are, if they are only a string or an integer, it's okay, we know we don't have an attack. But if the user parameters are actual SQL statements, then by definition we have a SQL injection. And so then in that case, the RASP engine will just report an attack. And so we know that we found the vulnerabilities at this point. So We have similar analysis for several class of vulnerabilities, and so we took the data that is in our database and we computed aggregated figures for all that those kind of vulnerability exploitations. So there is a big difference with other reports that you may find. We don't focus on potential attacks that we have detected. We focus on actual vulnerability exploitations that we have spotted.

**12:59 Robert Hurlbut:** And so understanding a little bit more about what the report is and some of the goals, and you were trying to help, if I understand correctly, you're trying to help teams, or the purpose is to help teams understand some real attacks and see those results and help them understand that these are not just theoretical. Sometimes we read a report SQL injection is the top or some other attack is the top. What does that really mean? But you're actually trying to put some reality behind it. Here's what we're seeing and here are the most common things that we're seeing resulting or as a result of some data that we've collected.

**13:39 Aviat Jean-Baptiste:** Absolutely. The initial reason why we dug into that data was to build data extract for the OWASP to help the OWASP build the OWASP Top 10 2020 that may actually be delayed in 2021. And so that's how we started to dig into those figures. And so I was reading the extract behind my spreadsheet and I was thinking, oh my God, so many great insights in this dataset. We need to share it more. And so I shared with the team. And so that's how the idea of this report was born. And obviously, We shared the data with the OWASP as well. And so yes, this data is grounded into reality because that's not just detecting, yes, we have this trend of attack. It's more— so we don't really know the trend of attack. What we know are the actual vulnerabilities that may be present into your application. Now, this report is not like the perfect source of truth because We don't protect against any kind of vulnerabilities. There are some vulnerabilities that we don't cover yet, for instance, and so you will not find everything into this report. But on the class of vulnerabilities that Scream is covering, we believe that this is a nice insight of which vulnerability is more prevalent than others and which language might have more difficulties to be more secure facing one vulnerability than one other. And so all those insights can be really helpful to application security teams that can help their engineers in prioritizing into which kind of defense they should put first.

**15:34 Chris Romeo:** So if we think about this from our audience's perspective, What would you say is— what will I take away or what will I get from this report if one of our audience members is sitting here saying, okay, I'm going to invest an hour in reading this report. JB was telling me about it on the podcast here. Like, what would you tell them? Like, how would you entice them to say, here's why you should go ahead and spend that hour reading this report?

**16:02 Aviat Jean-Baptiste:** Depends who you are. If you are, I don't know, a Gartner strategist, then you might find interesting that vulnerabilities such as SQL injection or cross-site scripting are still prevalent in today's applications. And so that may come as a surprise to some of us because we know that modern frameworks, they have good defenses against cross-site scripting, they have good defenses against SQL injection, but that's still not perfect. So that's one of the things. The other thing that you might find interesting is that we found that we had 4 times more attacks in the past year than over the previous one. So we had like a rise in attacks. So, and when I say attacks, I mean vulnerability exploitation, right? It's in the context of this report. And so we might think that the world is becoming more and more safer and safer, but it's actually not what this data is showing. So, I'm not saying that this data is worrying, but I try to think and see how we could explain that. And one way we could explain that is that the world today has more and more software developers than it had 1 year ago or 5 years ago, right? The world has a huge demand for software engineers. And so, one of the consequences of that is that software engineers' training is becoming shorter and shorter. And so we know that historically, the software engineer training does not take into account security that much. And that's expected because they have a very complex job. Security is only one facet of it. And so the shorter you make the developer training, the less they will spend on security. And so the more likely they are to write bugs that actually have security consequences, so-called vulnerabilities. So this really makes the world evolving quickly not in the direction of being more and more secure. And so obviously this may change with new tools, new frameworks, better information around all of that, but that's not what the report is showing to date. So I think that's my answer if you are a Gartner analyst right now. My answer, if you are a CTO, an application security professional, a CISO, what you may want to look for into this report is how your own company might be vulnerable to some particular threats. So let's assume you are a PHP-first company or a Java-first company, then this report will show you for each platform, what are the prevalent vulnerabilities. Some of them are surprising, some of them are not. For instance, we know that Node.js is using a lot the MongoDB database, and so this kind of vulnerabilities are obviously prevalent in the Node.js world.

**19:18 Robert Hurlbut:** So with that in mind, and let's take— I know you give different views, the Gartner view, the CTO, and so forth. Let's take the application security person. What was one maybe surprising thing that you learned from analyzing this data that could be helpful to that application security person that maybe they need to think about or maybe they hadn't even thought about? Was there maybe one or two things that you found?

**19:44 Aviat Jean-Baptiste:** To me, one thing that was surprising is prevalence of SQL injections and cross-site scripting exploits. So very, very important proportion of those. So what we saw is that about 70% of the security events consisted of SQL injections and XSS exploits. So that's a lot and there is a huge prevalence. So probably there should be a focus on protecting your applications against SQL injections and cross-site scripting vulnerabilities. So you have many ways to do that and this report is not sharing that much about it. The recommendations are findable. You can do content security policy. You can ensure that all your applications are using a templating engine. You can use static analysis to ensure that you are not using dangerous functions or review the usage of those functions. You can have some training for the developers to help them understand what they are, sensibilize people for those things during pull requests, etc. That's typical. You have similar recommendations for SQL injections. But that's one takeaway. When we are Often looking for business logic vulnerabilities and different kind of things like race conditions, for instance. What we have here shows that we still have a prevalence of those pretty old classes of vulnerabilities because like SQL injection were born like in the early days of the web. Cross-site scripting is a bit more recent, maybe 2005, the first reports on that, and 2010 really really popular. But we can see that those old vulnerabilities are really, really prevalent.

**21:29 Chris Romeo:** So we did talk about, we've already kind of mentioned a few of the key takeaways just have come up in conversation from the actual report. And I don't want to give away all the answers too. I want people to actually go read the report and understand, you know, some of the other things that are in there. So I want to ask, I'm going to skip over kind of the key takeaways that we may have already discussed. And I want to focus in on a question about all of the data in the report, are there any trends that point towards one language or one framework being better from a security perspective? And, you know, the caveat being you're about to enter the world of, you know, people that are super passionate about— they're like, wait, JB was saying my language or framework was, you know, I can't believe he said that. So, um, but I'm okay. I'm okay if we offend some people by saying that they're their language or framework might not be as secure as some of the other ones. But is there anything you took away from that looking at the different languages and frameworks to say one of these is better from a security perspective?

**22:33 Aviat Jean-Baptiste:** Yes, there is. So first of all, I'd like to do a small disclaimer. Again, this data is not— it's a state amongst our customer base. So it's not the entire world. And we also have like no report to date for Go because our Go agent was released pretty recently. And we don't have .NET, for instance, because .NET is a work in progress. So like we don't cover everything. Now, amongst what we cover, the findings is that consistently applications that are not using frameworks are 3 times more likely to suffer from vulnerabilities than applications that are using frameworks, right? So I don't really want to give a hierarchy of frameworks here. And actually we found that, for instance, in the world of PHP, whether you use Symfony, Laravel, or WordPress, you have basically the same likelihood of getting attacks, which is like 9%, 8% actually. Whereas when you are not using a framework, the likelihood goes up to 61%. So you have a huge discrepancy here. And the thing we would recommend, and I don't think that's a big surprise, but we can draw a conclusion further. The thing we want to recommend is that you should use a framework. So make sure that whenever you start something, you should use a framework. I think that's pretty grounded today, and we take it for granted. Now, probably if you are a CISO of a pretty large company, you have some legacy applications at some place or some other. So if some of those applications are not using frameworks, probably you should put them on top of your list, and you should have monitoring or protections on top of that. Maybe you should do threat analysis, threat modeling on that because if they are using some sensitive data, they are likely to have a lot of vulnerabilities. And so they could be a good entry point for attackers. So you should highlight them in your attack surface mapping and make sure that you go and you protect them as much as possible.

**24:44 Robert Hurlbut:** So that's a great point about use of frameworks and making sure you use a framework. But here's another question I was just thinking about frameworks is, even when you use a framework, there are sometimes good ways to use them and not so great ways to use them. In other words, there might be several ways to do the same thing, and it just depends on making sure you pick the right approaches and so on. Did you analyze that far in terms of, or that detailed in terms of maybe correct usages of the framework versus not so good uses of the framework?

**25:21 Aviat Jean-Baptiste:** Yes, so at Apple, the philosophy towards APIs API design is make— so the API should make simple things simple and make complex things possible. So that's like the mantra of API design. And I think that's an amazing good practice. And that's one of the practices that should be implemented in any API, whether you are doing a web framework, a cryptographic API, or whatever. All of the web frameworks or most of the web frameworks, they have great API for doing SQL query, for doing HTML rendering, JSON rendering that are pretty safe if you use them correctly. And that's where the trick is, right?

**26:10 Chris Romeo:** Right.

**26:10 Aviat Jean-Baptiste:** If you use them correctly. Some of those APIs are super easy to misuse. In Rails, the difference between escaping HTML and not is an equal sign, for instance. In Rails, you don't have escaping when you do orderBy. So all of these are small caveats that are still weaknesses from the original API that were put in the templating engine or in the ORM. And so each language, each framework has more or less of those caveats. And so you can think of a framework such as Express in Node, for instance, where the framework is really minimalist, and so it's up to the developer to use their own ORM, to use their own validation library, their own routing library. And so all of that makes it pretty hard for a developer that does not have a great consciousness of security to pick the right tool or the tool that is more suitable than others from a security standpoint.

**27:14 Chris Romeo:** And so when I'm looking at some of the findings that were language-specific, One of them is just really jumping out at me on the page, and so like, and I'll just kind of run through them real quick. So like the PHP applications, 3 times more likely. Okay, I get that. Thing, you know, primary 70% are SQL injection, cross-site scripting. That makes total sense. The 70% of Ruby apps were susceptible to SQL injection attacks. That one seems like an enormous number to me.

**27:45 Aviat Jean-Baptiste:** Yeah.

**27:46 Chris Romeo:** And as somebody who spends a good amount of time in Ruby on Rails where there's an ORM and there's a framework set up to help defend against SQL injection attacks, that's the one statistic that's kind of blowing my mind a little bit. So can you provide a little more context on that one?

**28:01 Aviat Jean-Baptiste:** Yeah, this one is surprising, I agree. And so one of the confirmation, may I say, on that is that if you take the HackerOne report from 2020, they also ranked SQL injection very high in the vulnerabilities that their hunters have found. So SQL injections are still prevalent in today's world.

**28:24 Chris Romeo:** Yeah.

**28:24 Aviat Jean-Baptiste:** But yes, I would not have expected that much of a prevalence. Now, for Ruby on Rails applications, that's something that I know especially well because when we started the company, the first agent that I written originally was the Ruby one. And so all of our first customers for the first 6 months, maybe even a year, were Ruby customers. And so I spent a lot of time proofreading the vulnerabilities that Screen were reporting in Ruby on Rails applications. And so very often I spent actual time with our customers, tell them, okay, you have this vulnerability. The customer was saying, no, no, it's not possible. I'm using this ORM, look at my coding practices. And so in the end, we were looking together and we were still finding that, yes, this endpoint and this parameter is not sanitized. And so you have several reasons for that. One of them is that, for instance, you always need to do something that is a bit strange. In Ruby on Rails, if you generate your database with the Ruby generator and the migrations, et cetera, it's pretty compelling to use because it really fits the object model of Rails. If you don't, and if you are using a database that was created by other means, then you need at some point to do more conversion some things to link that existing data schema into your Rails data model. And so that's where you can try to start doing some custom SQL queries. And as soon as you start doing that, things that cannot be easily done in the ORM, then you start putting yourself at risk. Another thing that we found analyzing the stack traces of the vulnerabilities, because like one of the good point of having those findings inside an application is that for each vulnerability that we catch, we have the stack trace. So for Ruby on Rails, we analyzed all of the stack traces, and what we found is that you also have a prevalence of admin interfaces that are allowing people to do actual arbitrary SQL injections. So one of the hard things in security is prioritization because we all have limited resources. All AppSec teams that I know are outnumbered compared to the number of engineers, of software developers that are in the company. And so the key thing that you need to do as a security practitioner is to prioritize and focus your efforts on the right thing. So I think this kind of data is very helpful in helping you prioritize and understanding what is the context and how All of the applications, all of the teams that you have in your company might be more or less likely to put vulnerability in their code. And so I think having a data-driven decision model to help a given team implement CI, to put more runtime protections on your applications, just to build your security strategy JB, thanks for taking the time to share this report with us and explain many of the different pieces of the report.

**31:42 Chris Romeo:** And I'm definitely adding to our episode backlog a conversation with JB about building a security product.

**31:48 Aviat Jean-Baptiste:** I'd love to join you on that, Chris and Robert, for sure.

**31:52 Chris Romeo:** Yeah, I think there's some definitely some good insights to be drawn there and some fun, some fun things to explore. So, thank you very much, JB.

**31:59 Aviat Jean-Baptiste:** Thank you very much, Chris and Robert.

**32:01 Chris Romeo:** Thanks for listening to the Application Security Podcast. You'll find the show on Twitter @AppSecPodcast or on the web at www.securityjourney.com/application-security-podcast. You can also find Chris on Twitter @edgeroute and Robert @RobertHurlbut. Remember, security is a journey, not a destination.

---

Source: https://appsecpodcast.com/aviat-jean-baptiste-the-appsec-report/