Episode 7

Developers vs. Security Training with Jim Manico

Published on: 9th July, 2021

In this episode of AppSec Builders, Jb is joined by security professional Jim Manico, founder of Manicode Security to discuss Application Security, Developers, and why they should be trained to build Secure Applications .

About Jim:

Linkedin: https://www.linkedin.com/in/jmanico

Twitter: https://twitter.com/manicode

Jim Manico is the founder of Manicode Security where he trains software developers on secure coding and security engineering. He is also the co-founder of the LocoMoco Security Conference and is an investor/advisor for Nucleus Security, BitDiscovery, Secure Circle and Inspectiv. Jim is a frequent speaker on secure software practices and is a member of the JavaOne rockstar speaker community. He is the author of "Iron-Clad Java: Building Secure Web Applications”  from McGraw-Hill.

Transcript

Intro / Outro: [00:00:02] Welcome to AppSec Builders, the podcast for Practitioners Building Modern AppSec hosted by JB Aviat.

JB Aviat: [00:00:14] Welcome to this episode of AppSec Builders I am JB Aviat and I am honored to welcome Jim Manico, who, on top of being a famous, opinionated security professional, is also the founder of Many Good Security, where she trains software developers in secure coding and security Engineering he is also an investor advisor for many companies, frequent speaker on secure coding practices and a book writer with Ironclad Java Building Secure Web Applications. Jim, why don't you introduce yourself as well?

Jim Manico: [00:00:50] Jean-baptiste is a pleasure to be on your podcast and your show. And like you said, I'm an opinionated application security professional. I just hope that my opinions are helpful to you and your audience.

JB Aviat: [00:01:04] Opinions are always helpful, especially when they are held by smart people. So, yes, definitely. And I'm looking forward to have you sharing a bit more about that with our listeners. So, Jim, thanks a lot for joining us today. So when we are familiar with your work, we can notice that your primary focus is developers. So you train them, you write books to educate them. You contribute to a lot of OWASP resources around education. Why that focus centered on the developers?

Jim Manico: [00:01:40] I believe that the application security industry traditionally has primarily been about security testing and dev ops and all these different pieces that are about assessment of the security of an application. And I do not believe that you can achieve security through testing. I believe that the only way to truly do application security is to get developers to build secure software and to utilize tools and techniques and processes that will help developers, author, secure software. And I believe that our industry places very little focus on that important specialty because it's hard to sell an idea. The idea that you must change your process, you must change your engineering capabilities and similar. It's not something that sells in the marketplace. It's education, which is not a very big part of our industry. So that's why I focus on that, because it's my specialty and it's also my belief. That's how you really do application security is to enable developers capabilities around security in some way.

JB Aviat: [00:02:54] And a so you've been doing that for a while. What are the big changes that you have witnessed over the past year?


Jim Manico: [00:03:01] I think the acceleration of dev ops is very interesting. Now, Dev Ops has been around for 20 years. This is about automation around the building, testing, deploying in other aspects of the SDLC. And we were doing that in the late 90s through a lot of custom scripts and similar. And I think that today there's extremely modern tool sets like Jenkins', GitHub actions and similar, where I can build a significant security centric dev ops pipeline in a really short amount of time now, especially if I'm using GitHub actions. Click, click, click. And I got dependable that I got static analysis and some grep. I got dynamic testing and similar testing tools really rapidly in terms of setup. And I believe in a few years that when we're using GitHub in similar repositories, advanced security testing that we see today will be natural and automatic in just a few years. Other trends that I have seen are for more intellectual is the migration away from traditional session management and the movement of stateless session management using JSON Web tokens and the OS two and the open IDE Connect protocols and other JSON Web tokens centric standards. This is a very big departure and change around how secure Web and API applications are built. I also see a lot of new changes in HTP response headers, content security policy, the different response headers to delete site data at logout time, ways I can configure referrer policy or very granular now the advancement of cross origin, resource sharing and the capabilities being available in most every browser. I think that all those response headers have changed dramatically in just the last couple of years to give developers more security capability in modern browsers.


JB Aviat: [00:05:07] I definitely agree that don't get me started on JSON Web tokens, but. She already did, and that's a huge fan of the and we took in, because I think that's an interesting evolution in the world of security. It's a bit complex to configure. Right. There are several things you don't want to forget. And to me, that's a tool that has very interesting properties. But that is a bit hard to give, as is to developers like these specifically need the training and education in order not to misuse it. Right.


Jim Manico: [00:05:38] I've got to be honest with you. Using JSON Web tokens is radically more difficult. You now have key management secrets, management, the implementation of log out and idle time out, which was easy. In Session management is a challenge with Jason Web tokens that you can certainly achieve more scale. And if you're using micro services, you kind of need to use adjacent web token because it's difficult in a scalable, performance friendly way to tie sessions together among many small services. So, Jean-Baptiste, I really like the back and front end pattern, the PDF pattern where I have more of a traditional session between my JavaScript client or Web client and the main API that serves as a reverse proxy to a fleet of micro services that is back in my private infrastructure. So that way I can still benefit from the statelessness of micro services and performance, but still have a traditional session between the JavaScript client and either a gateway or a reverse proxy API. So all the mess of JSON, Web tokens and micro services are behind the scenes. So I actually agree with you. I really don't like JSON Web tokens when you push them to the client all the way. I try to avoid high powered access tokens and Jason Web tokens from being in a client in particular. I mean, like a browser web client, because there's no good place to store sensitive data long term in a Web client. It's just not mature enough for that yet. So if you're going to use JS on Web tokens or if you're forced to because of the use of micro services, again, the pattern is called the B F f the back and front end pattern, which basically takes the mess of micro services and Jason Web tokens and pushes it back into your private infrastructure aligned


JB Aviat: [00:07:37] With your line. Yes. Things. So I think that's a very interesting time to be in security today because. Yes. Of things evolving. You mentioned headers, Clinton's security policy. So, yes, we have a lot of new tools that are evolving and changing the security capabilities that are into the hands of the developers. So that's a necessary step in the journey towards being more secure. There is no question about that, though. Those tools and those security primitives are still extremely complex to implement. If you take a look at the latest security headers that are centered around the Specter meltdown, protections like the complexity of those is really insane. And I feel either we need weeks of training for the developers that will have to use that properly. And Fulu is the mess of like its original house brothers, etc. though we need something in between, like a layer that will automatically configure the application. And I think this is where there is a builder between what you can teach the developers. And no one has infinite time to teach developers and what the tools should be responsible of. And so you said one very interesting thing in your introduction, Jim, is that you teach the developers to use the right tools. And I think that's that's a big part of the business, is to help them find the right tools.


Jim Manico: [00:09:07] So let's talk about Spectre and meltdown briefly. Spectre and meltdown is the ability to read data out of a CPU cache. Right. And in my world, this is mostly a problem with the Web browser. Like I'm worried about Chrome and Firefox and similar having an attack with malicious JavaScript cross site scripting primarily, or a malicious third party library that allows malicious JavaScript to read data out of a CPU cache. And we saw a demonstration from Google who provided a JavaScript demo around exactly how this could be done. Now, how is this problem solved? The problem is usually not solved by a web developer building a website or an API. The problem is solved by a browser developer and I do not teach browser developers. I teach the masses of Web and API developers how to build secure web and API applications. But the defenses that really stop spectre and meltdown with my understanding. Traumatised is like site isolation and similar that is built into browser technology, also the use of an HTTP only cookie will also help in stopping these class of attacks. And I do agree to teach a browser developer how to be more resistant to CPU attacks like Spectre and Meltdown. That is extremely sophisticated knowledge. But as long as Web developers and API developers are using basic security principles, they're doing OK. And the other thing is, if someone is using a very old browser, there's very little a developer can do to stop these classes of attacks. So I also recommend that developers as much as they can, they use JavaScript detection to understand what browser is being used by their customers and as best as they can do not allow older browsers to use their sites and APIs. So luckily, it depends on which developer you're trying to influence for Spectre and Meltdown. I need to influence the browser developer and for web for the standard web API developer. I'd like them to use HTP only and other cookie protections and to also make sure that they're only allowing as modern of a suite of browsers as they can possibly get away with.


JB Aviat: [00:11:38] Yeah, I would even say we have to influence you designers and of the browser vendors. But I think one of the flaws here was that no matter how safe your browser getting JavaScript execution in one page, which is not so hard, if you think about server kind of attacks on Fatty's, for instance, would allow you to read any part of the memory. And that's something that doesn't depend on the browser, actually, because it's like just running JavaScript. And I think that was the big demonstration of the Google demonstration making you like a Specter expedition mainstream. So one of the way to counter that was that Scerri a very complex idea such as Skouras, etc. And I think that is the same story for about any kind of interface for API that is very complex from a security standpoint. And you have examples, for instance, of tools that made the life of security protocols easier. And so one example that I like is in the ACL, for instance, the crypto library that took a very opinionated stance that what kind of helper's it will offer to the developers. So it's much less flexible than a regular crypto API, but you don't need to be a security expert in order to use it. What do you think about those initiatives?


Jim Manico: [00:12:58] First of all, you mentioned NaCl. So this is a cryptographic library conventionally known as Lib's sodium. I believe that does correct. Yes, it does. Good crypto in a library and I think that is a great idea. They are very opinionated in decisions they made there that have stood the test of time that are very good. I believe similar libraries for crypto like Google. Google has a library called Google Tenke, which is also exceptional in the very opinionated decisions they made. And so I like that idea because Salib Sodium and Google Tenke are really usable utilities, even though they're opinionated, they're not so opinionated, where they're not usable, they're very usable and very straightforward to use. So if you're being very opinionated but still providing usability for developers to author software, I do like that idea as well. And I do not think that the suggested defenses around stopping Spectre and meltdown are reasonable. And I don't think that's the way the problem is solved. I think that, again, I believe the problem is solved in the browser itself and Firefox and the Google team and other teams we're building browsers are actively working on making those protections automatic by doing various types of browser isolation and other types of defenses. But to your point, if I do get JavaScript execution in a website, yes, I can likely read the CPU, but I can also do request forgery.


Jim Manico: [00:14:29] I got cross-link scripting. I could modify content. The point I'm trying to make Zapatistas any kind of cross site scripting event is game over if the attack executes. Yes. And to your point, I don't think the real issue is spectre and meltdown. I think the real issue is that cross site scripting defense, otherwise a better name would be content. Injection defense in a web application is madly destructive and there's no simple way to stop that. The common developer who's using backbone and angular and 30 other JavaScript libraries, it struggles to keep them up to date. Massive amounts of JavaScript code. They're almost always. Going to have cross site scripting, and even if you're using the latest version of react with best practices, it is still easy to make a mistake in a variety of different ways that will bypass Riak security. And so I think that's the bigger problem. Zhovtis, not Specter meltdown or how to approach it, but just how to build a secure user interface on the Web period. And we see that content security policy three, which allows for dynamic. I'd also say that a trusted type standard is helping a lot in providing that capability. The only problem with content security policy, three, it's not supported and e 11 or even worse, it's not supported at all in Safari and ie eleven support.


Jim Manico: [00:16:03] Only some of my customers need that. Most of my customers don't use ie 11 anymore. But according to the W3 C browser statistics i.e. elevons, global use is statistically zero percent at this point as of last month. So we see I 11 finally starting to go away. But content security policy three. I was looking at the Safari Technical preview and within the last couple of weeks I see players that are building content security policy three support into Safari. So now now if we can get developers to implement CSP three, I like Anon's Pastrick, dynamic policy perspective, YOLO and Weichselbaum from Google's research and I limit what browsers I allow my customers to use. I can build some extremely rigorous security today. And I think that when we go ahead a year or two year, two or three and I have CP three everywhere and techniques to limit browsers and a little more awareness about third party libraries, that the capability of developers to build a secure application without excess is going to be more realistic. That's my hope job. At least all we have is hope. But I do agree with your conjecture. The cross site scripting and complicated Web applications is really hard to avoid, even with talented, security centric developers. And that's a problem with web development in a big way.


JB Aviat: [00:17:40] I agree it's still easier to avoid today than I think 20 years ago when you weren't using, like, templating engine server side. Yeah, the things were on one hand. Come on. And on the other hand, pretty neglected even at the beginning by security people. And so, yeah, I think things move to a very, very positive way. And we can only think Google here, who is really moving for a while, w3 C and leading implement this implementations we sickroom and I trusted. Stipe's was born from an initiative to solve the excesses problem at the Google scale internally. And so that's insane to see how well they managed to solve it internally. It's not like 100 percent solved with breathtaking. It's like 90 percent solved. And sharing that to the broader audience is amazing, as you said. Yes, it's not trivial to implement that shit within your customers. What are the strategies that you see to actually implement this kind of initiatives? It's complex at the scale of a company at scale.


Jim Manico: [00:18:46] It's extremely difficult. It requires at least today, it does require educating developers, which is not a very scalable activity. I realize that's difficult. So my goal is usually to educate the lead security champions of each developer team around content security policy using the Spagnuolo YSL bomb methodologies on top of libraries that use trust types. So who are these rock stars we're talking about? Chris Cristoff from Google is the author of Trusted Types, and Michelle Spagnolo and Lucas Shubham have been giving talks about how they roll out content security policy, which uses XP Level three on the conference circuit. I'm a big fan of their methodologies dramatised in any hero's journey you have helper's. I'm on a journey to learn about secure coding. Even though I am a teacher by trade, my real profession is being a student so I can learn these technologies enough so I may teach them properly and on my own journey of learning about this, these three individuals have helped me the most. Again, I want you to look these people up and look at their work. Michelle Spagnuolo, Lucas Shubham and Chris Cristoff. Those are the three top defenders of excess on the planet with the kind of. Knowledge and work that they are doing, and I'll credit Michael West as well from the W3 C, who has done a lot of work with content security policy at the standard level. Google is no perfect company. No one is. But a lot of the engineers at Google have led the charge in providing good security standards so we can build secure web applications.


Jim Manico: [00:20:34] And the way that I work with companies to achieve this knowledge at scale is not to influence every developer. I can't do that realistically in training, but I can influence the main security champions that reside in each team who are dedicated and responsible for secure software. So I try to influence those leaders so the knowledge trickles down to other members of the team. And that, of course, assumes that a company even has security champions embedded with their developers in the first place. But that's the best way I think, that this kind of knowledge will trickle into large companies, because as a side note, it's a lot of application. Security leaders have been telling me that education is not important or that education is not going to work. And I strongly disagree. We do not have methodologies that automatically and magically provide security without developers being involved. We still need developers to write secure software. I know that your company does some great work. I know that you're working on a product that does provide great security, but that's not magic and it's not going to work alone without developers being involved in some way. So I'm still like a lone wanderer with my cape and walking stick wandering slowly through each company that I can to influence as many technical leaders as I can to teach them about secure software as best I can.


JB Aviat: [00:22:17] I know you'll need to learn. There is no question about that. And the education is definitely a critical pillar of any security strategy. I think there is no question about that and it will likely be for a very, very long time. But you cannot disagree with the fact that some classes of vulnerabilities have disappeared from time to time. If you take the right framework with the right language, you can get rid of some classes of vulnerability.


Jim Manico: [00:22:47] Yes, I was debating on Twitter with one of the leaders of LinkedIn. Now, if I had a company that had one framework and the experts working on that one framework, then I can eliminate classes of vulnerabilities and not have to teach my developers about that class vulnerabilities. But remember, you've been around for a long time. How often do you show up to a company and they only have one framework and one way of building Web software? That's very rare.


JB Aviat: [00:23:18] Well, it happens till the day where you buy into the company. You're right.


Jim Manico: [00:23:23] We have this one framework. Oh, yeah. You have that one framework than that other version of your one framework on that project. Then on that legacy. One has an even older version of our framework. Oh, yeah, that acquisition has all those frameworks. So the idea that a company has one framework only, it's always up to date that is extremely rare. That's like less than one percent of companies. The reality job at least is I'm using twenty frameworks. I got hundreds of developers. We're all doing different things and having some knowledge around building secure software is fundamental to understand how to remediate the issues that show up in testing. I wish I only had one framework if I only had one framework that was maintained by many architects who knew application security then at I agree with you and that does show up once in a while. But it's the exception.


JB Aviat: [00:24:18] This it's not a realistic assumption. But let's look at the broader picture. So I'm an optimistic person at The Hurt. And so my thinking is that progressively most frameworks, Mr. Enbridge's will evolve towards an ecosystem that is more and more secure by design. If you take a look, for instance, at the Cerruti nineteen ninety five and I wrote a lot, I was very insecure because you had zero frameworks. Now you have things such as Symphonie all Harvell that amazing had handbells in the job of the group. It's much easier, just isn't perfect and you still need to read the documentation etc. but it is better if we take a look at a time frame of maybe ten to twenty years from now. Don't you think that most framework's. They have evolved towards a more secure version of themselves and you can call be a fool.


Jim Manico: [00:25:19] One of my dearest friends from Canada is a friend of mine, a developer named Jean Baptiste Lipless. And I haven't seen him in over a decade. So just to say the name of aTest again reminds me of my old friends. I'm gonna keep using your name I like it's a great name. But that aside, I agree with you 100 percent. In fact, Schumpeter's I'll even say this unless we have a radical transformation in the security capabilities of frameworks, there's no chance of achieving application security at scale. So not only do I agree that that's what's going to happen to the primary frameworks, we have no choice but to accomplish that. And if we don't accomplish that, we're not going to achieve appliqué security at scale. So I think big governments like the French government, the US government, whoever's got extra money lying around, I believe that if governments want to invest in cybersecurity, they should be spending billions and billions of dollars to assist. The major frameworks of the day have integrated security. Nobody wants to spend that money, though. I watch, like different governments, they'll spend billions of dollars for bull shit. Forgive me, they will, but they won't spend money to really address the heart of our security problems, which is the fact that our languages, frameworks and components that we use to build software today are all radically difficult to secure or need massive updates.


Jim Manico: [00:26:55] So not only do I agree with you, I think it's the only hope for society to solve this problem. And my belief is that if I was in government or politics or policy, I'd want to see all this money that governments are spending on cybersecurity now that they spend it on building elite developer teams who will work with the frameworks to integrate and test security at the framework level in better ways. That's my hope and dream. You don't quote me on the job when I retire from commercial activity and I'm much older and greyer than I am now, then I'd like to go work for some government with big money and funding to build teams, to work at the framework level and improve the security of frameworks so every company and organization in the world will benefit from those enhanced frameworks. I know some of that work is happening now, but it's happening slow. And the framework still all of them still require advanced, complicated knowledge to use securely. And that doesn't scale.


JB Aviat: [00:28:08] Yes, and that's a good thing. Actually, I was thinking about some of the good security traditions of the past years and thinking about like Ruby that popularized a lot of good practices in the Web. I was thinking about risks that could serve the before the Flooz instead of C, for instance. And I was thinking about Crume individual Thracian Demy, Christine, that you mentioned earlier. That's also brutal enough to goodness. And none of that, I believe, was led by a government entity, writes Rabinowitz's Basecamp, Croom's Google and the rest is musila unless I'm mistaken.


Jim Manico: [00:28:45] The point is it's all happening too slow. Ruby on rails. The only problem with Ruby on rails is that you have to use Ruby on rails. What an awful framework with one of the best security capabilities of any framework. The way that their data flow works. And I am not a fan of Rails. I can never, ever use it for an application.


JB Aviat: [00:29:07] But in Jim's opinion here.


Jim Manico: [00:29:11] But I want to be objective and they've done incredible work when it comes to security. Absolutely. But this is happening too slow. What about spring? And I can still make big mistakes in rails. I can still make big mistakes in spring and symphony and every other framework out there still requires sophisticated knowledge. And the slow progress we're making is not enough progress. And I don't even know why I'm bringing up government and policy. I rarely discuss those topics. We're in an era where governments are starting to spend big, big money on recovery around the world. And I would just like even just a couple of billion dollars directed at developers that are advanced, being paid properly, working specifically to do security in the common frameworks of the day. Just let's hit spring. Let's go hit JBoss. Let's go hit Symphony. Let's give Ray. Also, more security support the net berry needs some support, just 10 framework's one hundred million dollars worth of development effort for each of them and we can revolutionize the world. But again, nobody wants to spend that money. They'll spend it on a new choo choo train or some other like manufacturing plant or like some other like research project. But let's spend real money, real money on the most common frameworks of the day. And we can advance application security more than the slow, gradual progress that we've been making for the last 20 years.


JB Aviat: [00:30:49] And so you're a Java expert, I think. And so if you had to start from scratch and you Java project today, what would be the most secure system that you could recommend?


Jim Manico: [00:31:02] Ok. This is, again, very opinionated. No. One, I would minimize my use of third party libraries to the essential only, and I would probably use a small handful of libraries like for my JSON parsing I would use mostly for my cryptographic needs. I would use Google Tink and for my framework I would not use spring. I would use my own custom lightweight framework for my project specifically built by an architect of my team. And on top of that, no framework servlet endpoint. I would use a small handful of well vetted libraries with a commitment to keep them all up to date on the client. And I'd most likely use react. I believe react has the best balance between usability and security capabilities and I would like military style training, all of my react developers before I let them write code for me, because in about an hour to four hours I can turn to react developer into a react security architect. I've been tutored on that to my friend Ron Paris, who I work with, one of the best security people I know. So I use react and I'd really minimize the use of third party JavaScript libraries besides react, no tracking or shift left. I really minimized what libraries I use on the server. Again, I use my own lightweight framework, so if there's a problem, I can modify the code myself. We ever had to dive into spring to fix a problem.


Jim Manico: [00:32:45] I don't want that burden. And even though it will take me some extra work to build some of the piping that comes out of spring, I'd rather have that code myself that I can work on. I'd also make sure I only have senior developers on my team. I do not believe in junior developers and that is a harsh reality. I know a lot of junior developers who are having trouble getting work because a junior developer who can't really operate in a production environment, they end up costing a company more than they benefit from that developer unless they stay there for many years. And most Start-Up developers don't stay for a few years. They become junior developers. They join the company, they get some training, they can get a bigger salary and they leave. And that ends up being an expense to a company, not a benefit. So my advice is, in your career as a developer, go from developer to middle developer and skip the junior developer part. No one needs a junior developer to skip it and go right to being an advanced developer through your own boot camp training or whatever. But nobody wants a junior developer because they end up causing more harm and taking up more time than being good. And this is I don't say this to be rude. I say this to be realistic about the state of our industry.


JB Aviat: [00:34:05] So how do you go from out of school to not general developer?


Jim Manico: [00:34:10] Just skip it on your resume to say senior developer? Honestly, I would recommend coming out of school to go take a bootcamp, take like a like a three to six month boot camp after you get your initial university degree and learn some specialized knowledge in the frameworks that are being used today. I know for me as a developer, I was already a hobbyist developer doing a lot of extra work outside of school, but it's not fair to recommend to everyone. So I would say finished university degree, then go to a coding boot camp just for a few months. So you really gain some skills in JavaScript development, client side JavaScript, API development database development that are production quality and modern, and then go look for a job and see how much more of a salary and see how much more opportunities will be available to you when you have realistic skills that makes your product. Right away and forgive me, John, but you know my limitations. I'm going to admit something to you. I'm a capitalist. Please forgive me. Oh, no, please forgive me. I'm a capitalist. But running capitalist companies, we want employees to be productive to help us make some capital. And so bringing in a junior developer who has no need to stay. And I spend all this money and effort training them and then they leave. But I don't want that and neither do most big companies. So my advice, I'm going to university skip being a junior developer and jump right to being a productive developer. Thank you very much.


JB Aviat: [00:35:53] So what you're saying is that the universities don't do a good job at training developers, basically, right? No. Well, that's where the government could spend some of that money. Maybe.


Jim Manico: [00:36:02] Maybe so. Maybe so. But I think that if you want to be a professional developer, you're better off skipping university, go to a nine month developer boot camp on modern languages and development techniques, and you will have a better chance of getting a well-paid job than going to a university program. The problem is university professors are mostly not writing production code for a company. They're academics. And it's so difficult to keep up with modern development techniques that university, even the best ones, tend to be behind in what's needed in software development and for that matter, security and real development shops today. I feel terrible saying this, by the way, properties, I wish it was not true,


JB Aviat: [00:36:50] But I think that's the direction of the world anyway. We need more developers today than we needed 10 years ago. And 10 years from now, we will need even more developed than what we have today. So it's required as there is no choice but to have those education methods evolve. Otherwise, mechanically, the level of general developer will only go lower and lower. So what you're saying makes sense,


Jim Manico: [00:37:14] But it makes me feel filthy to say these words, though.


JB Aviat: [00:37:20] You train much more developed than I do. So I think you know what is out there very well. Thank you so much for sharing that to me. Is there anything you'd like to share before we finish?


Jim Manico: [00:37:31] I just ask that if you're listening to this podcast, please say hello to me on Twitter. That's where I do most of my public communication these days. My Twitter account is manicured m a and I c d, e. So if you're listening now, please just say hello to me on Twitter. Tell me if you care about secure software and secure development. That's all I care about.


JB Aviat: [00:37:55] If you disagree with anything that you just said, just let us know on Twitter. We'd be happy to share your thoughts. Thank you so much for joining me today, Jim. That was a really, really fun to talk about all of those value subjects with you. I really appreciate I can't wait to actually meet you when the real world comes back. And maybe in Paris,


Jim Manico: [00:38:16] Paris, one of my favorite places in the world, I will be in Paris as much as I can. So let me see if I'm pronouncing your name properly. You try to be Frenchman Jean Baptiste Aviat.


JB Aviat: [00:38:25] My God, yes. That's perfect. That's perfect. But next time you can just call me Jim. All right.


Jim Manico: [00:38:33] You've got to be perfect.


JB Aviat: [00:38:36] Thank you so much for joining us, Jim. I really appreciate. Have a good day.


Jim Manico: [00:38:40] Have a good day yourself.


Intro / Outro: [00:38:42] Thanks for listening to this episode of AppSec Builders. You can find all the resources discussed during this show on AppSec Builders dot com. Be sure to subscribe to our podcast to get updates on our upcoming episodes.

All Episodes Previous Episode
Show artwork for AppSec Builders

About the Podcast

AppSec Builders
The podcast for practitioners building modern AppSec.
AppSec Builders features practical and actionable conversations with application security experts and practitioners. Topics range from understanding and solving classes of vulnerability, building protections to efficiently scale with your business, and core best practices to strengthen your security posture. AppSec Builders is hosted by Jb Aviat, CTO and co-founder at Sqreen and former Apple Red Team member where he was a reverse engineer, pentester, and developer.

Contact us at appsecbuilders@sqreen.com

About your host

Profile picture for Jean-Baptiste Aviat

Jean-Baptiste Aviat

Jean-Baptiste Aviat is the CTO and co-founder of Sqreen. He spent half a decade hunting security bugs at Apple, helping developers fix them, and developing protections used by millions of devices.

Prior to Apple, Jb was a full-stack, white-hat hacker for a consulting company, developing numerous security tools in whatever language he needed to hack into.