Tanya Janca -- What Secure Coding Really Means

Tanya Janca, also known as SheHacksPurple, joins the Application Security Podcast again to discuss secure coding, threat modeling, education, and other topics in the AppSec world. With a rich background spanning over 25 years in IT, coding, and championing cybersecurity, Tanya delves into the essence of secure coding.

Tanya highlights the difference between teaching developers about vulnerabilities and teaching them the practices to avoid these vulnerabilities in the first place. Instead of focusing on issues like SQL injection, she emphasizes the importance of proactive measures like input validation and always using parameterized queries. She believes teaching developers how to build secure applications is more effective than merely pointing out vulnerabilities.

She also explains the importance of a secure system development life cycle (SDLC). Software companies often state "We take your security seriously." Tanya believes the phrase should only be used by companies that have a secure SDLC in place. Without it, the phrase is rendered meaningless.

Discussing the intersection of coding and threat modeling, Tanya shares personal anecdotes that underscore the need to view systems with a critical eye, always anticipating potential vulnerabilities and threats. She recounts her initial reactions during threat modeling sessions, where she is surprised by the myriad ways applications can be exploited.

One of her most crucial takeaways for developers is the principle of distrust and verification. Tanya stresses that when writing code, developers should not trust any input or connection blindly. Everything received should be validated to ensure its integrity and safety. This practice, she believes, not only ensures the security of applications but also makes the lives of incident responders easier.

Toward the end of the podcast, Tanya recommends This is How They Tell Me the World Ends," which offers a deep dive into the zero-day industry. She lauds the book for its meticulous research and compelling narrative. The episode wraps up with Tanya encouraging listeners to stay connected with her work and to anticipate her upcoming book.

Links:

Alice and Bob Learn Application Security by Tanya Janca
     https://www.wiley.com/en-us/Alice+and+Bob+Learn+Application+Security-p-9781119687405

This is How They Tell Me the World Ends by Nicole Perlroth
     https://thisishowtheytellmetheworldends.com/

WeHackPurple
     https://wehackpurple.com/

FOLLOW OUR SOCIAL MEDIA:

➜Twitter: @AppSecPodcast
➜LinkedIn: The Application Security Podcast
➜YouTube: https://www.youtube.com/@ApplicationSecurityPodcast

Thanks for Listening!

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Transcript

0:00

We're honored to host the remarkable Tanya Janca, widely recognized as SheHacksPurple. Tanya is a brilliant mind behind the best selling book, Alice and Bob Learn Application Security, and the founder of WeHackPurple, a comprehensive platform dedicated to teaching the art of creating secure software. With a rich journey spanning over 25 years in IT, coding, and championing cyber security, Tanya has donned many hats, from serving in public sectors to leading at tech giants, and from founding trailblazing companies to spearheading community initiatives. An award winning speaker, Tanya's voice resonates across six continents, advocating diversity, inclusion, and kindness in the tech world. We'll explore her insights on secure coding, delve into the nuances of DAST in a DevSecOps pipeline, and uncover her perspective on the transition to SEMGREP. So... Gear up for an enlightening conversation with the one and only Tanya Janca.

Chris Romeo: 1:41

Hey folks, welcome to another episode of the application security podcast. This is Chris Romeo. I am a general partner at Kerr Ventures and also the CEO of a stealth cyber security startup joined as always by my good friend and threat modeling compadre, Robert Hurtlebutt.

Robert Hurlbut: 2:02

Hey Chris, yeah, Robert Hurlbut, Principal Application Security Architect at Aquia, as well as the threat modeling lead there, and really glad to be here with you as well, and uh, exciting talk today on this podcast.

Chris Romeo: 2:17

Yeah, we have a, uh, a guest returning for the third time. Um, that's, that, that puts her into very elite, an elite category with the likes of Adam Shostak and Jim Manico. I think those are the only others who have made a, uh, a third or more appearance here. And so, Tanya Janca has been featured a couple different times on the AppSec podcast with Nicole Becker, hacking APIs and web services with Dev, DevSlop, and then with Nancy Goresh talking about DevSlop, the movement, that was back in 2017 and 2019. So it's been a few years. Tanya, welcome back to the AppSec Podcast.

Tanya Janca: 2:54

Thank you so much for having me. And gosh, I am in good company with the hosts and with Adam and Jim. That's awesome.

Chris Romeo: 3:04

And so I think, uh, we wanted to kind of start diving directly into this idea of secure coding. I know that's something you've been doing a lot of thinking and, uh, and working on in the last number of years. And so let's just, let's start there. Let's start by talking about, from your perspective, when we say secure coding, what are we talking about?

Tanya Janca: 3:26

Okay. This is such a good question. Thank you. So When I started, um, giving training, uh, with WeHackPurple, it wasn't even called WeHackPurple yet, it was just, Hey, Tanya, I heard you left Microsoft and your startup blew up in your face. Did you want to come train our devs while you're figuring out what you're going to do next? And I was like, yes, please. Um, and everyone else that I saw on the market was focusing on all the vulnerabilities, like teaching the OWASP top 10, teaching how to exploit things, how to find vulnerabilities. And I was like, what if instead I taught them the things you need to do? in order to not have those vulnerabilities. So rather than teaching them what SQL injection is, let's talk about input validation. Let's talk about, you know, always using parameterized queries rather than, you know, cobbling together a system command, which is a lot of power, and then just sending it to execute and just hoping for the best that it's not evil. Right? And so I decided to go with What I think we need to do to write, to build secure applications, the types of things that are important to make sure you do. Uh, and then on top of that, of course, uh, both of you, I'm sure agree, having a system development life cycle or a secure system development life cycle. So security steps, whether it be like threat modeling or running some automated tools to find vulnerabilities or hiring a super awesome expert that comes in and actually tests and verifies or reviews the code. Whatever steps you decide to do, but to support that you have actually coded securely. Um, so train them to do the thing you need and, and then verify that we didn't miss anything. Um, so that's what I decided to focus on instead. And it's funny because, um, a lot of companies immediately said, yeah, but you're going to also do the top 10. And I was like, yes, sir, I will do that. So I added that basically immediately because it was not acceptable without it.

Robert Hurlbut: 5:23

Yeah, you can't get away with that, right?

Chris Romeo: 5:24

So when we think about. Yeah, and we think about some of the, some of the principles of secure coding. You mentioned input validation. If we think outside of any particular language, what are, what are the, what are the primary pillars that you're thinking about when we think, when we say secure coding?

Tanya Janca: 5:43

Okay, so the, so the first one is validating input of any kind and connection of any kind. And so maybe those two should be separate, but basically if someone's talking to me or someone's sending me something or I'm, I'm asking for something and I'm receiving it, whatever it is. I need to make sure it is what I'm expecting and that it's safe for me to use it. And so, um, in my, uh, in my first book, I put, um, like, trust no one, not even your mom. And then I tell the story of how my, my mom sent me a virus and I opened it because she's my mom. Um, and she would always send me these word documents with like no topic and it would just be like template dot whatever. And it just meant review my grammar, Tanya, because we would check each other's grammar because we used to work together. Um, and, uh, and so I just opened it like a moron and then virus, virus, virus. Um, and so even... your most loved ones, you need to validate, like, if you need to validate from your mom, you definitely need to validate from, like, Google or Facebook or that third party API that you're calling or whatever it is. And so when you are receiving something from someone, whatever it is, like, validate. So I call it input validation, but I even mean, like, I'm going to open something from my database, and it's not a pre programmed database, so it's not like, the months of the year or the different provinces within Canada. Cause I'm from Canada and that's the accent. At some point, I will say"aboot" and then I will deny it just to be clear. Um, but, uh, so, like, if it's a predefined thing where you know that it's hard coded in there, basically you're probably fine, but, like, if it's something where this is stuff we got from the user, you should assume it's dangerous. You're connecting to an API. It's dangerous. So that's the first thing. Then the next thing is, oh, I'm going to talk to someone. I'm going to connect. So we talk about authentication and authorization all the time, but Chris and Robert, it is still missing all the time. Um, and so. Validating who we're talking to, who we're supposed to be talking to, who we think we're talking to. Like this meet might mean, so we check they have a certificate, that's great. It's a valid certificate, that's great. It's from a CA, excellent. Is it for the hostname that we said it was? And whether you want to call this input validation or validation of who you're talking to, like authenticating the correct person and authorizing them correctly, um, and I know authorization is different and I want to get onto that too, but the next thing is output encoding. And so it's not sexy. I know everyone's like cross site scripting and it's dying. It's dying really slowly. It's still very alive. Like, I know people that use Angular, um, and React, which is awesome. It's, it's built in, that it output encodes everything to try to avoid cross site scripting, and that's great. But I still find cross site scripting, like, literally constantly. And I want to not do that anymore. Like, I'm, I'm done. I'm over it. Let's, like, stop building that. So if we always output in code, like, if we're not using a language or framework that does it for us, Making that a habit and even better, if you can make Um... So I used to be a.NET programmer before I joined Microsoft, then I was really a.NET programmer. Um, and we made like a little DLL where I worked, and you would just put URL ENCODE, or just eventually made it just ENCODE, and it just figured out what it was and did it for you. And we would pen test this template, and it did all sorts of security stuff for us, and it was totally awesome. So we didn't even have to think about it. It was like just dot encode. And then if we looked through stuff and we didn't see dot encode, we're like, what are you doing putting that on the screen? Danger, danger, Will Robinson. And it was just so easy for us to see because we've made it such a habit where we work. And so, yeah, making sure whatever you're getting is safe to use and make sure who you're talking to is who you think you are and you should be talking to them the way you're talking to them. And then output encoding everything. Can I add a fourth one, which is parameterized queries? Okay. Last one. I swear. So if you are going to talk to a database, don't send a system call that's like, I've seen this where they're like, I have a parameterized query. Actually, let me back up. So a parameterized query means it is a function that's built into your database server. It's in there. And you've written it to do whatever it is, like find, uh, you know, users where username like this and return, I don't know, their expiration date, let's say. And so then you feed it a parameter, the username. When you do that, that database server, whether it be, you know, an SQL type or no SQL type like Mongo, it takes away all the power and treats that parameter just as data. It can't execute as code, it doesn't interpret it, which means it's not dangerous. So even if I put a bunch of scripts into it, and I think I'm an awesome elite hacker, It's just going to take all that power away and look for a username named that, not find it and say, sorry, folks, you're out of luck. Right? And so I've seen developers where they're like, oh, I did make one, except for what the parameter is, is the complete system call that they've cobbled together from terrible user input. That's totally unsafe. And it just says, execute my parameter. I'm like, no. Okay, so you have followed the letter of the law, but not the spirit. You're still in trouble. But yeah, like if, if for every system call, if we could do it safely, uh, that would, that would save a lot of heartache and incident response time.

Chris Romeo: 11:24

So I'm, I'm hearing a lot of talk about languages in the realm of secure coding. Now, like some of the popular guidance that's being thrown around now is like Rust is the thing. Like if you're doing anything where you're using C and C++ today, you should be replacing it with Rust. And then, now immediately with code. But when you think about secure coding from a language perspective, like, what's, what's your hierarchy, uh, I guess of, of languages. Like, I feel like there are still some languages that are more dangerous than others, but then you do have the Rusts and the Go's that are at the top of the stack where everybody's saying Go is awesome, Rust is awesome, from a security perspective and just from a usability perspective.

Tanya Janca: 12:12

So I haven't heard usability with Rust. I've heard that Rust is hard to program with compared to C. I have not, like, I've looked it over a little bit, but I've never actually built an app with Rust at this point. And I've heard developers tell me it's really hard. And so, I've been told that's why it's not adopted as often, because it apparently is more difficult. I don't know if that's true, but I've heard it repeatedly, which is a signal. Uh, and I'm listening to the signal, I listen to the feedback. That said, if, okay, so, I would prefer if you're going to write a new app, you wrote it and it was low level, that it was in Rust over C. Because it has memory safety built into it and that just resolves a ton of problems. I remember Mozilla, maybe two years ago, released this article where they said they switched to Rust and it removed 73 percent or something of all of their vulnerabilities. I was just like, well, if anything convinced me ever, this article certainly, if I wasn't convinced before. So that's very powerful. Maybe it was 2020 when they released it, but either way, good article. Thanks, Mozilla. Thanks, Mozilla. So if you can, but if an app's already in C, do you have the money to change it? And that is a question I come up with, with clients a lot, where it's like, yes, we could re rate it, but that'll cost about a million dollars, and we only get about 1.5 million dollars worth of revenue per year from this app, and like, we were thinking that slowly we would retire it, and like try to move customers off over to this, so does that even make sense at this point? Right? So like a lot of the, so if you're going to build something from scratch, yeah. Choose Rust over C. Um, choose Angular and React, more modern, um, and frameworks, rather than an older one. You know, don't use PHP...

Chris Romeo: 14:02

People still use it.

Tanya Janca: 14:04

I know they still do, and I find the bugs. But so if you can choose a more modern framework, always choose the newest version. Like, Chris, I've worked in.NET shops where, um, so I don't know if it's still like this, but when I was doing.NET regularly, you'd have to update all of these things on your desktop that you were compiling everything on. And they'd be like, oh, well, I'm supporting this older version. So I'm just going to write the newer version and the older version, so I don't have to mess around with all my DLLs compiling things. And I'm just like, no, no, please, please don't do that. Right? And so I like, whenever we can choose the newer thing, we should choose the newer thing. By default, it's generally safer. Except if it is a brand new technology. So, not a new framework or language, but a brand new technology, like when serverless came out, or when no SQL came out, or when containers came out. At first it's like, it's 1999 again! There's bugs everywhere! And it's the same bugs as before, because we forgot to input, or validate our inputs, and we were like, yeah, I'll take connections from anyone! And all those things that we forgot about, because we were in a rush to get to the market. Um, so I would say not with brand new technologies, you want to be careful with those, but when programming frameworks, especially whatever the newest version is, the newest version of the library, all of those things. I worked somewhere once and this guy had down, downgraded us to SSL 1. 1 when I wasn't looking, um, because there was a printer he wanted to connect to and it'd be like a couple thousand dollars for us to upgrade our printers around to all of our offices. And I was like, so you made that decision without me. I'm like, see, frowny face. He's like, yeah, I'm like, you're in trouble. He's like, I understand. Um, and then we talked about the risks involved in the cost and we decided to get new printers. Um, so yeah, I think that, um, if you can be a part of that conversation, when devs are choosing new technologies. Like, I remember when I was making my AppSec Foundation courses, my friend Ray looked them over for me, Ray from HelloSecure, and he said, Tanya, what about every time the devs are choosing a new language, framework, technology, whatever, you being at that meeting and steering them away from the danger zone. Gosh, yes, that's such a big part of my job that I forgot because it's so obvious you want to be in that meeting. And explaining to students, like, this is so high priority for you, you really want to be there. Because if you can... I worked somewhere once, Chris, where they wanted to use something called Centura. Have you ever heard of Centura? Okay, so don't look it up, you'll get nightmares. So it's a thousand zillion years old. It's got like no security built in and they're like, oh, well, we have all these older devs. I hear referred to them as older gentlemen who had worked for them for 20 plus years who didn't want to learn.NET because they're going to retire in 5 to 7 years and like.NET's hard. So we would just make up our new apps in Centura for a few more years. So they had work to do. And he's like, so no, no, instead I'm going to pay for training for everyone. We're all going to learn.NET like good little devs, or they can go work somewhere else. How about that? Um,

Chris Romeo: 17:19

Sounds like a better, uh, a better scenario

Tanya Janca: 17:22

But, but sometimes that's the reason, it's like, oh, our, our staff are comfortable with this and I'm like, respectfully, our staff can learn, they're really smart. That's why they're not our ex-staff. They're really smart. Have faith.

Chris Romeo: 17:34

That's why they're not our ex staff. I like that one. So, when you think about, we've talked about some things. That we don't want people to use. We mentioned PHP. mentioned, I mean, I would even say C and C++. You kind of have to use them in some situations, but if you're building something new, definitely put in the effort for Rust. You mentioned Angular and React, the latest versions. Those are, those are good things. Uh, what else is in your stack of recommended languages, frameworks that you think people should be? If somebody is in a green field environment where they're like, okay, I can, I can do this brand new, I can do something from scratch. What are you recommending that they add on top of an Angular and React?

Tanya Janca: 18:18

um, I like Ruby, um, so I have not made very much stuff in Ruby, however, um, so that framework, the RubyGems, so the framework itself protects you against, um, like cross site scripting, um, SQL injections, like there's a bunch of stuff built into the framework which is super nifty and nice, but on top of it, um, All the gems are supported, or not all of them, a large percentage of the gems are supported by the Shopify team. So their AppSec team has this giant bounty, and they fix the gems for the whole world. So they've spent a couple million dollars at this point, I believe, paying out bounties, and they themselves and their team just constantly finding bugs and fixing all those gems. So you sort of have a support team built in, and that's pretty nice compared to... So Node.js, Devs love it, but we've seen some issues when things have no paid support, right? Like there's no, so there are wonderful volunteers who work their buns off and I thank them, right? But when you only have free devs working on stuff, you don't have a paid pen tester coming in, you don't have a bug bounty checking for these things, like we've had some disasters there, right? Same with, um, so.NET, supported by Microsoft. Microsoft, when they say we take security seriously, they actually mean that in like a billion dollar way. Uh, they're not just saying those words, they're living those words every day, which was part of why I wanted to go work there back in the day. And it was cool to work at a place where everyone, where I would tell them, Oh, I found this security thing. And first of all, sometimes the answer was, We know, we're on it, thank you. Whoa. Okay. You already found it and you're working on it. This is amazing. We're about to push the fix. Wow. But if not, they're like, tell us more. We will do this. Like, do you know what I mean? And so you have like a team there, full time paid people, working on fixing that. And they have the bug bounty thing going as well. Versus like these open source ones where, like log4j, so Java's. Good, I learned it in college, and then I kissed it goodbye professionally, mostly until pen testing. Um, but like it because it's supported by people working for free you get what you can You take what you can get, like, um, you mentioned our old episode with Nancy Grisha and Nikki Becker, where we talked about OWASP DevSlop, people would submit PRs, and then me or Nikki wouldn't fix them, and they'd be like, hey, are you going to fix this? I'm like, I have a full time job, and I have like the oldest others, like, I'll get to it when I get to it. Like, I'm sorry, Rick. I'm like, I'm busy. So usually my friends, Rick and Adrian, but anyway, and they're just like, oh man, I'm like, why don't you fix it? You're, I know, you know, right. And so you, so I feel the pain of these open source maintainers. Like my project was like this big compared to this, the types of amazing libraries people provide in Java. And so, uh, like open source is a beautiful thing, but if it's not being supported, it can be a messy thing. And so I try to go with things where I know there's support for those libraries that I'm going to want to choose from whenever possible. Um, so yeah, and I'm still, I'm kind of making a list right now. So I'm working on my next book, which is Alice and Bob Learn Secure Coding. And I'm, I have like a list of frameworks I want to cover, but it doesn't mean I'm going to like what I say about them. So I've picked the most popular ones and I'm going to do like a thing of, here's a bunch of tools to check out, here's like best practices in this language. And then here's gotchas, like don't use any of these terrible functions and try not to do this. And like people often get caught on that. And once I've done all that research, I think I'd have better advice on this, um, other than like look at the support for all, like having, having the Shopify team submit like just hundreds and hundreds of fixes for all the Ruby gems is just like, Oh, that gives me faith. I wish more companies were like that, quite frankly.

Chris Romeo: 22:12

Yeah. And I've used Ruby on Rails as well. And Shopify does, does build a lot of excellent gems that they share with the community as well to help other startups and other companies just just use the technology. So Last question on this this avenue. I know we're still talking secure coding. That's okay, we happen to like secure coding,

Tanya Janca: 22:33

Me too.

Chris Romeo: 22:34

But this is a bit of a softball question But coding and threat modeling. What's the, what's the intersection between these two very important things?

Tanya Janca: 22:46

Oh, I love this. Um, Robert's got a serious look on his face, like I'm listening. Um, so when I first started attending threat modeling, I felt like my brain exploded. I was just like, why would it? Why would someone ever do that with my beautiful little app I made? Oh, and I made a slide that's in one of my most recent talks, and it's this woman, and she looks like this, like this surprise look on her face, and above it says, You're gonna do what with my app? And that's how I felt the first time someone, and we were talking about voter suppression. And it was, like, all the different ways that someone could try to use my app in a way to make it so that Canadian citizens wouldn't be able to vote, or would be discouraged from voting, or be afraid of voting. And honestly, I was like, whoever's going to do this, I want to punch them in the face. This is terrible. Um, as a person that, like, has worked many, many hours and even years of her life to help people vote, right? Like, I'm just like, That's awful. How could someone do such a thing? And so then I started looking at all of our systems very differently in regard to voter suppression. Then they pointed out, Hey, like, did you know people like money and some people are willing to steal it? And I was like, Oh my gosh, we're out to handle money. And as then I learned about, um, STRIDE, which is a threat modeling, methodology. And so I do the, it's an acronym. So like S is for spoofing, T is for tampering, et cetera. I started doing those in my head in conversations with devs. And I'd say, let's review your architecture. And then I just ask questions. And at first I was really, you know, I was just learning flying by the seat of my pants being mentored by this person at work. And I would start off with like, you know, if you're going to hack your app, how would you hack it? And it, for the product owner, like what keeps you up at night? Like what terrifies you that could happen and let's make sure it doesn't. So tell me all the things that worry you. And then I'm going to like, look at the app for these threats. Right. And I got better at it and better, and I'm very excited to report. I'm going to help teach Adam Shostack's.... And by help I mean like I am a small assistant who is learning as well. Um, his course at OWASP Global AppSec this year in DC. I'm so excited to learn from Adam. Um, because I've never had formal training. I've just like read books and articles and like done my best, right? And being able to sit there with a whole bunch of people and see everyone else's ideas is amazing because as a dev, all I ever wanted to do was make it work. And once I started seeing. Oh, this is how someone could abuse your app. This is how someone who thinks outside of the nice, let's build stuff box, the person that's in the breaker frame of mind, this is how they think. And it really changed the way I looked at code. It changed the way I used apps. I started pressing things I wouldn't have pressed before. Um, just like I'm on the last page of the results, but the next button's still a link. I'm definitely clicking that button, right? And so, I feel like with developers... It doesn't necessarily mean they're going to know, Oh, I should use the security header off at the beginning. But eventually it became, Tanya, if this is going to be like this and that's going to be used like that, should we do this? And I'm like, Ah, this is so fantastic. Like they're, they're learning, they're listening. It's, they're growing, if that makes sense. Because I was so, I don't want to say naive, maybe like innocent and wholesome is a nicer word. Um, like I just saw the good and all the things and how to make it, make my customers really happy. And then once I learned like, oh, someone could misuse this, then it's like, oh, and I can protect my customers too. And so I, I feel like it, it applies more to design and usage and not as much to secure coding. But I, I have been able to use threat modeling to explain why we need security headers and input validation and some of the major ones. That's great. It's not a direct correlation for all of the things I want, but it helps a lot. It helps me get buy in a lot, especially for bug fixes or changes to architecture. What do you two think?

Robert Hurlbut: 27:03

Well, we think it's the best thing, but yeah, I agree. Uh, teaching developers. I mean, my experience teaching developers, um, I see, uh, well, varies, but for the most part, wow. Why didn't anybody tell us this before? And, uh, it, it really opens them up to possibilities that they may not have thought about before with their code. Um, certainly I want to get it done. I want it to work, but what could somebody do with this? I hadn't thought about that. And so I've seen the same thing. They, they really appreciate it. And it certainly, um, broadens their view of the code they're writing and the things that can be done and improves their code, ultimately.

Chris Romeo: 27:49

Yeah. And I, my experience, I've seen what I like to refer to as the light bulb moment, which y'all, both of you have taught lots of classes. And so you've had this experience too, but as a, as an instructor slash teacher, there's nothing finer than when someone's sitting in the class and all of a sudden it just hits them. And they're like, Whoa, okay. And I have to tell you this very quick story. We were teaching a class, uh, about security and threat modeling when I was at Cisco at our internal security conference. And we had a guy and he's sitting there and all of a sudden he just, he had his light bulb moment and he's like, Hey, um, I need to, I need to go back to my desk for a bit. We're like, this is odd. Like we're in the middle of the class. This is a, this is just a single day class. He's like, You don't understand. The thing we were just talking about, I added that to our app or to our product, and I gotta go fix it. So, I'll be back. He left the class, he came back about 90 minutes later, and so like, of course we had to stop for a moment and go, okay, let's do a recap here. How did the fix go? Did you get, and you know, he, he enjoyed telling us what, what he had done and then what he had done to fix it. But that light bulb moment is just such a precious thing for when it, when a student just gets it and hopefully they stay in the class most of the time. Um, but when they get it, it's always a fun moment.

Tanya Janca: 29:17

I had this happen during a CTF as well, where we got past the username password by using SQL injection. And one of the women on my team was like, would this work for MongoDB? Like, is there such thing as no SQL injection? And I said, yeah. And she's like, cool. I got to go right now. And she like ran out of there. And then she's like. Everything's fine! And she changed, she's like, I was at work until like 11pm, but everything's okay now. But it's magic, it's the best in the world to know you just helped someone a lot.

Robert Hurlbut: 29:58

agreed. Absolutely agree.

Tanya Janca: 29:59

Chris, I heard there's new topics that you have you want to talk about.

Chris Romeo: 30:05

There's, there's, there's a few more, but let's, let's, well, let's talk about your move to Semgrep. To make sure we have some time to cover that. We have a few more things we'd love to talk about, but if we run out of time talking about kind of your, your new move, that's okay too. So give us some context on what's happening.

Tanya Janca: 30:22

Okay, so, um, I started a little company called WeHackPurple in February 2020, the worst time ever to launch a company. Um, but we survived anyway. And we had, have a giant online community. We have a big online academy with low priced AppSec, secure coding, um, encryption, etc. classes. Uh, and then we give corporate training as well. And we have a fun little newsletter. And, um, I. I was in, uh, an acquisition arrangement last year that didn't work out. And so we called it off because we are adults and we talked about it and was like, Ooh, recession, things changed. Ooh, let's, let's figure out a way so we can divorce, but like in a friendly, nice way. So that's good. Well, I mean, divorcing is bad, but you know what I mean? It ended as well as it could have, uh, and on the best possible terms. And so then I was like, okay, so I'm just going to give training again and do this and again, do that. And. I sent out an email to tell all of the WeHackPurplers, um, what was up and someone responded and said, wait, so you still own WeHackPurple? And I said, yeah. And they're like, yeah. Is this still for sale? Uh, and then I spent the next like five months negotiating with many different companies and meeting a lot of people who I never thought would hold a meeting with little old me. Uh, and then after talking to many of them and getting like a lot of offers, uh, so Semgrep made an offer that was, that was good, but it was, um, it was like the team and the people and the job that I would do and what they wanted to do. So I had people offer will give you a lot of money to destroy WeHackPurple and run it into the ground. Uh, and to take your courses and delete them forever. And I was like, oh cool, but I don't like money quite that much. Um, these are my people! I spent so much time finding them! I can't throw them away. These are like my friends now. Um, they're important to me. Um, and so Semgrep was like, yeah, we have a giant community too, and we all want the same things. And so like, what if you could give training for free? And what if like, you didn't have to turn a profit and like, you could just do tons of community events, um, and like, just expand your training more and more. Cause when you run your own company, you barely have time to like, go to the bathroom in between meetings. Uh, Chris is like nodding and smiling because he knows this feeling and it's like 10 p. m. and you're doing bookkeeping and you're like, oh, yeah, I'm supposed to do that one on one with one of my staff and like, you're doing lots and lots of business things that are really important, but it takes away from your ability to like, develop new content, help more people spread your message. And so they're, uh, They're just like, what if you've led education and you educated our customers, but you also educated the public and not just like how to use our product and like our products, the best blah, blah, blah, but like genuine actual education. Like what if you taught people secure coding, like everyone, what if you just did that? And what if you could have, you know, the community events you've been having, but more and more and more and like have support with like, like a whole team helping you instead of like. You and your, like, your tiny team. So I had a team at WeHackPurple, but they were small and like, our budget was very little and modest. Um, and like basically the corporate training paid for almost everything else that we did. And so I'd have to do lots of deals all the time and sit through lots of vendor forums. Oh my gosh, Chris, Robert, vendor forums. And so they're like, we'll do all of that. And you can just like, do the things you want. for free and then also like work 40 ish hours a week instead of like a hundred. And I was like, oh, this sounds so appealing. This sounds really good. And when I started my company, I didn't have children, but I met someone while I was actually like locked up in quarantine. Um, uh, and then that person has children and now I have children. Like they're really cute and they're like, play with me, mommy. And I'm like, yeah, um, instead of like working until 10 p. m. And I was like, you know, Semgrep's making a really good, um, like, life changing, like, idea, like, this sounds really cool. And so Um, we did a project together and we really liked it and then we started another project together and we really liked it and I was like, I think we should put a ring on it and make this serious. Um, cause I was like, I really don't want to do a thing where it doesn't work for either of us. Like last year where, you know, if neither of you get what you want, that sucks, right? You want everyone to get what they want. And so, um, so far it's been really wonderful. And, um. Yeah, I am basically starting to create content for them. I published on their blog for the first time this morning. Well, other than the, hi, I'm a new employee blog, but like a real blog post. Um, and so, yeah, I just get to like write and teach and like whole fun events and I get to do everything for free. I don't have to charge money now. And so like. One of my goals with WeHackPurple was to, I don't know if the word is democratize, but when I learned AppSec, there was no book. When I learned AppSec, I couldn't go take a class and just like become an AppSec engineer. I joined OWASP. I had to start my own open source project. I had to do like 25 zillion things and I had to pay for most of it myself, um, partially because of the Canadian American dollar exchange value and like how the Canadian dollar is trash, um, and partially because like things just cost a lot of money and the Canadian government, who I worked for, didn't have a lot of money. And so I was like, part of my career goals are I want to perform good. And one of the ways I feel I can perform good is by making as many new AppSec engineers as I possibly can. And as many more secure coders as I possibly can. And when I was at Microsoft, they kept talking about scaling. Like we need to scale your efforts. We're not going to hire five more Tanya's. You know, instead of flying everywhere, what if you wrote more? What if instead of, um, you know, writing every single person an answer to an email, you wrote a blog post that answered that email for everyone. What if, you know, you, so then I decide to write a book and they're like, this is great. And then I was like, and I'm gonna start my own company and they're like no, don't leave us! But they've been so supportive and wonderful and amazing. Um, and so this is like me scaling even more, being able to like basically have this giant powerhouse behind me, supporting everything I do, which is totally amazing. Um, and like having also like tens of them willing to teach as well. So I don't have to teach every class anymore because they'll teach a bunch of the classes. I've never had that with WeHackPurple. It was always like, I'm the subject matter expert. I couldn't afford people like me to come work for me. Do you know what I mean? And so, uh, it's pretty exciting for, from a pers personal perspective, but from a professional perspective, perspective, even more like, plus I get to work with my friend Clint Gibbler, and for like years, he's like, we have to figure out a way to work together. I'm like, we do Um, and so now we have.

Chris Romeo: 37:28

Yeah, it's so cool. And I was checking in our archive. We did an episode with Drew Dennison in June of 2020. So this was pretty early on in R2C's journey of, as a company. I think it was just, there was just a couple people, I don't even know if they were funded yet at this point when did this interview, but, uh, it was, it was just, it's fun to be part of the history of companies and watch them blow up now and, and just think, Oh, you know, we talked to them in the very early days when they were trying to figure out, do they have something here?

Robert Hurlbut: 38:02

right.

Tanya Janca: 38:04

well, they do some pretty cool research, so if you wanna meet any of them, you just let me know. They're, well, they also make really weird products. And that is part of my excitement too. It's not just a copy of everyone else's products. I'm like, I want to do weird stuff. Like, why create like the 45th SCA tool that does the same thing as everyone else? We need to be different or we shouldn't bother. Be audacious. Um, and so that is part of their, uh, values. So their values and our values almost completely, perfectly overlapped, except for the, let's be audacious. And I was like, Ooh, I like that. that a lot.

Chris Romeo: 38:41

it is a good way to put it about, uh, not doing the same thing everybody else does. So, all right, we got time for a lightning round here. This where, this is where Robert shines. Like, Robert's moment the lightning round, if I had music, I would play it now. Like, intro music for Robert coming into

Robert Hurlbut: 38:57

intro into the lightning round. All right. Uh, Tanya, we have some questions here. We typically ask three. Uh, so what's your most controversial opinion in or on application security and why do you hold that view?

Tanya Janca: 39:12

Okay. So my controversial opinion is that one or two false negatives are not going to bring down 99. 9 percent of companies, or 99 percent of companies. So a lot of companies suggest like more modern tooling, uh, like a second gen SAST or, um, like things that go way faster, like exponentially faster. Or I'll be like, oh, let's take out some of these tests that are unlikely or whatever. And they're like, we can't miss a false positive. We'll die. And then I'm like, cool, do you have any criticals that are in prod right now or any highs? And they're like, well, yeah, and I'm like, what's your SLA for fixing them? And they're like, oh, you know, like we try to fix them in one business week, but we have some that are like five years old that we've known about for five years. And so we're not really meeting our SLAs. I'm like, cool. So if you miss a low with like a more modern tool, what happens? And they're like, uh, I mean, do you even create tickets? For lows, they're like, no. And I'm like, so most of the modern tools get all the highs and criticals and even the mediums generally. You're not even fixing mediums and lows. Like, they're not even on the table for discussion whatsoever. But if you miss one, it's the end of the world. So do you want a scan that takes eight hours instead of eight minutes, which is what the DevOps folks want and are willing to tolerate, um, because you might miss a thing you're never going to look at or talk about? And then... They're like, well, we have like, really, we need high security assurance. I'm like, okay, so are you doing counterterrorism? They're like, no. I'm like, does democracy like rest on your shoulders? And I've done counterterrorism and like, I ran as a CISO for the election in Canada, so I can be a snarky and say that, right? And they're like, no. I'm like, do you show like stupid training videos to people on the internet, like WeHackPurple, where there's like silly memes and cartoons that were like teaching you secure coding. Like, is that your level? Well, maybe. Do you really think like. You need to be perfect for that, or could you just be really, really good? Right? Like, are you going to spend those extra millions of dollars to go from really good security to perfect security? Well, no. Is anyone even looking at the results of that old tool when they come out? Well, sometimes we check in on them. Okay, so you can miss them because you're already missing them. You're not even reading them. You're not even talking about them. You're certainly not fixing them. You can miss one. And you won't die. And then they're like, oh, okay. And then I'm like, now let's have a more realistic discussion about your tooling. Like, are you getting what you need? Or are you just writing checks? Because writing checks doesn't secure anything except for my mortgage. It does do that. But other than that, there are no checks that secure systems. Right? And so let's have a more realistic discussion and like, let's work with your DevOps team or your, your dev team or your ops team or whoever, and like actually get crap done. And so, A lot of companies are like, we do need to be perfect. And I'm like, okay, tell me the real reasons why. And then we, I get a little tiny, tiny, tiny bit snarky. And it turns out usually their business model does not need to be perfect. Like, I want security to be really good. I'm an AppSec person. I care a lot, but I'd rather only find 10 bugs that are all true positives. And we fix eight of them. Then I spend weeks and weeks looking through results. I find 200 things and the devs are like, that's overwhelming. I don't even wanna talk to you. Or we find 200, they go into the backlog. People fix one. Like I, we only have so much time. We only have so much money. I only have so many engineering hours and so much social currency. I can spend, I need to spend it where it counts and it can't be me trying to run something in the CI that takes six hours. That's not where I'm gonna spend my time and my currency that I have, my persuasion that I can do. And then usually by the end of the conversation They're on board Or they like don't call me again. I mean, maybe they don't like my opinion and that's okay. That's why it's controversial. Hot take! Okay, next question.

Robert Hurlbut: 43:14

Next question. Uh, what would it say if you could display a single message on a billboard at RSA or BlackHat conference?

Tanya Janca: 43:24

Oh I have so many things I want to say. Um, I get to say one thing? We take your security seriously needs to mean you have a secure system development life cycle. Otherwise, you don't get to say it. Otherwise, you have to zip it from now on. So, unless you have a secure SDLC, you are not allowed saying the words we take your security seriously. Send tweet.

Robert Hurlbut: 43:56

And the last question is what's your top book recommendation? Uh, it could be about security or not. You know, we've had many different answers and why do you find it valuable?

Tanya Janca: 44:07

Okay, so I, I have a lot of interesting books I've read recently, but the one I finished literally yesterday is called This is How They Tell Me the World Ends. And it's about the entire zero day industry. And how crappy it is and how basically regular citizens are paying for this giant cyber war. I thought it was ridiculously well researched. Like, like, thorough is an understatement. Um, and like the way that she slowly, the author like slowly lays out the entire thing. And at first I'm like, this is like a news report that never ends. Um, so I had to like warm up to the very, like, it's very formal and official and it's not like casual language like what I write and that's okay. Um, but I, by the end, I was like, no, no, I don't want it to end. I mean, I want the cyber war to end to be clear. Um, but it made me, um, more aware than ever before of like the zero day market. And like, I remember talking to someone at a conference and I was like, Really interested in this person. Uh, I was single, we're like flirting. And then they told me how they had sold a zero day on the zero day market. And I was like, you may not have my number. Um, I just don't want to be associated with someone that's going to sell a secret. Like. And it wasn't, it wasn't even to their own nation that they sold it. And I was like, I have to go. Don't even sit near me. You're scary. Oh, I like, I, I, I see why people, especially people that are like in economic danger, if that makes sense. Like people where it's like, they're going to starve or they're going to do this. I'm not trying to cast judgment on those people. This person had lots of money and could survive just fine. Um, but I. I really want to be one of the good guys more than ever, uh, reading about this book and helping people just build secure software from the beginning so we don't have nation states hurting people, like literally resulting in death, resulting in bankruptcy, resulting in, you know, retirement savings gone, like our job is to protect everyone. And, um, that's really important work, and I felt like the book made me feel even more passionate about the work that we do, and I didn't think I could. So, thank you, author.

Chris Romeo: 46:20

And I can, I can second that one. I read that one a few months ago and it's, it's very well researched, but yet the story is very gripping. You feel like you're, you're on, you're on the ride with them going, uh, through these various, uh, companies and whatnot that are these zero day brokers and stuff. So. Okay. We come to the end of our conversation here, Tanya. Let's leave our audience with a key takeaway.

Tanya Janca: 46:46

Okay, if you're writing code, do not trust anything that you receive. Um, even your mom, even if they're amazing, incredibly intelligent mathematician chemists like mine, who you love very much, can make a mistake and be infected with malware. Your database can have something in it it shouldn't. Even like a call to Google Maps, right? Like what you're receiving. So like I make calls to lots of APIs. Make sure what you're receiving makes sense before you use it. Like it doesn't. It's work, it's extra work, but it'll make your life better, and it'll make all the incident responders where you work, it'll make their lives better. Um, so hug an incident responder, if you're allowed, with consent, um, and, uh, and, and make their day better by validating every single type of input and connection that you get.

Chris Romeo: 47:37

Good stuff. Good stuff. So

Tanya Janca: 47:38

Oh, and, and also please read my blog. Read my blog and my book. Yeah, I'm supposed to tell people, like, subscribe and all those things. Do those things.

Chris Romeo: 47:49

Do all the things. Definitely. So Tanya, thanks for sharing, uh, your insights and, and wisdom and whatnot. It was great to, to reconnect with you here and next. When, when the book comes out, just let us know. We'll have you come back on. We'd love to take a closer look at the book and, uh, we've done a number of different book episodes with authors and so we'd love to have that conversation with you and dive into some pieces of the book to understand it better. So thanks for all you do, and we'll see you. Uh, we'll see you in DC in a, in a number of months.

Tanya Janca: 48:19

Awesome. Thank you both so much for having me and I'll see you next time.