The Modern .NET Show

S07E11 - The Security Expert Speaks: Tanya Janca on Learning to Code Securely

Sponsors

Support for this episode of The Modern .NET Show comes from the following sponsors. Please take a moment to learn more about their products and services:

Please also see the full sponsor message(s) in the episode transcription for more details of their products and services, and offers exclusive to listeners of The Modern .NET Show.

Thank you to the sponsors for supporting the show.

Embedded Player

S07E11 - The Security Expert Speaks: Tanya Janca on Learning to Code Securely
The Modern .NET Show

S07E11 - The Security Expert Speaks: Tanya Janca on Learning to Code Securely

Supporting The Show

If this episode was interesting or useful to you, please consider supporting the show with one of the above options.

Episode Summary

In this episode, we welcome back Tanya Janca, an expert in Application Security and the author of numerous influential books in the field. This marks Tanya’s third appearance on the show, where we delve into her new upcoming book, “Alice and Bob Learn Secure Coding,” set to be released in February 2025. Tanya recounts her journey from software developer to penetration tester before finally finding her niche in Application Security, emphasizing the importance of secure coding across all programming environments.

We explore the significance of her new book in addressing the prevalent gaps in secure coding education. Tanya shares that her inspiration comes from her own experiences and the mistakes made during her evolution as a developer. Having established training academies for developers, she recognized the critical need for comprehensive resources that cover secure coding guidelines for various programming languages and frameworks. The book aims not only to equip developers with necessary skills but to shift how security is integrated into software development from the outset.

Tanya also discusses common pitfalls in coding education, with a focus on the issues created by traditional teaching methods that often neglect security standards. She advocates for “secure defaults” in frameworks, encouraging developers to leverage built-in security features rather than developing their own solutions. Addressing the industry’s tendency to prioritize speed over security, she insists on incorporating security processes from the project’s inception, equating it to the safety procedures NASA implements when constructing rockets.

Throughout the episode, we touch upon the significance of soft skills in app security, particularly the need for effective communication between developers and security personnel. Tanya highlights how misunderstandings can lead to friction and emphasizes the importance of empathy and context in these interactions. This is particularly relevant when discussing risk management and vulnerability mitigation within organizations, where security teams must negotiate priorities with development teams effectively.

Tanya’s aspiration is clear; she seeks to empower developers by condensing her knowledge into easily digestible formats such as cheat sheets and interactive discussions, further promoting a culture of secure coding. She invites followers to engage with her upcoming live streams where experts from various fields will discuss key concepts and answer audience questions, a continuation of her commitment to accessible education in Application Security.

Be sure to check out Tanya’s website for more information on her upcoming book and to subscribe to her newsletter to stay updated on resources, cheat sheets, and community events centered around secure coding practices.

Episode Transcription

From the very first lesson of “Hello, World” they teach us to make insecure code. So the first thing with "Hello, World" is how to output to the screen. That is fine. But the second part of "Hello, World" is: you ask them their name, you take their name. you don’t validate it, and then you say "Hello," and you reflect their name back onto the screen with no output encoding. And then you just made cross-site scripting. And right from the very first lesson, we teach everyone wrong in pretty much every language, and so as a result we end up with a lot of people doing code the wrong way. Like, universities are still teaching lots of things wrong. And so I’m hoping that this book will help.

- Tanya Janca

Welcome friends to The Modern .NET Show; the premier .NET podcast, focusing entirely on the knowledge, tools, and frameworks that all .NET developers should have in their toolbox. We are the go-to podcast for .NET developers worldwide, and I am not your host: Jamie. I’m Delilah and I will be recording the intro for this episode because Jamie’s throat infection returned, making it tough for him to record this intro.

In this episode, we welcomed Tanya Janca back to the show. This conversation marks her third appearance on the show, and a slight change in focus to Secure Coding. We talk about how developers are taught to write insecure code from day one (or “Hello, World!”), about how her new book “Alice and Bob Learn Secure Coding” could help with that, the many hours of free education and learning that Tanya has created alongside the book, and how both data scientists and academics approach software development differently to some of us developers.

There are so many amazing security features in .NET. There’s so many. Like, because I… I wrote about eight different frameworks and .NET by far had the absolute most different security features. And part of it, some of them are from Windows. Some of them are from C… because I wrote about C# and .NET. And to be quite honest, audience, I mixed them up quite a bit because, "what is specifically C#, and what is specifically .NET," got a bit confused in my brain. But I’m like, all of it’s good. Do all of it.

- Tanya Janca

Anyway, without further ado, let’s sit back, open up a terminal, type in dotnet new podcast and we’ll dive into the core of Modern .NET.

My voice was created using Generative AI.

Jamie : [0:00] So, Tanya, welcome back to the show. It has been a little bit of time since you were last on. How are you?

Tanya : [0:07] Jamie, thank you so much for having me back. Things are pretty exciting right now.

Jamie : [0:12] Awesome. Awesome.

Jamie : [0:15] So, for those who don’t know, this is Tanya’s third appearance on the show. Tanya was originally on the show in episode 77, where we talked about app security. And then episode 105 where we talked about more app security because well we’re giving the game away here but app security is one of your things isn’t it Tanya?

Tanya : [0:35] It is. I’m a bit of a broken record actually. Yeah, can I introduce myself?

Jamie : [0:45] Oh sure . Sorry. Yeah.

Tanya : [0:46] No. But, basically, I was a software developer who switched over to, briefly, be a pen tester before she discovered that there was a job called “Application Security.” And yeah, that is my jam. And that’s kind of all I talk about.

Jamie : [1:02] Yeah, yeah, yeah. And yeah, we talked about app security. I think it was around the time of your previous book, right? It was around the time of Alice and Bob Learn App Security, which I have sitting next to me on my desk.

Tanya : [1:19] Oh, that’s wonderful. Yes.

Jamie : [1:23] Sorry.

Tanya : [1:24] No, that’s it.

Jamie : [1:27] It’s an often recommendation It’s something I recommend a lot to folks because I do a lot of work for different companies and work on a lot of different projects almost all the time. And so one of the things I do when I walk in, I’m like, “okay. Have y’all thought about app security?” And they, “go app what?” And I go, “right, okay. Here’s a book, go read it.”

Tanya : [1:49] Oh my gosh. Well I hope my second book ends up in that category, where it’s something that you feel good recommending.

Jamie : [1:58] Oh 100%, 100%.

Jamie : [2:00] For reference folks, I’ve received part of a version of the book to read, ahead of time, just so I can get my head around the stuff that we’re going to talk about which is awesome, thank you very much for that Tanya. And I will be recommending it to anyone and everyone because it is… I think it’s super important. Like, maybe we can talk about that now right? Like, how… what is the new book called and how important is it for people to be adopting the practices and advice in the book?

Tanya : [2:34] Okay. So my brand new book, coming out in February 2025, is “Alice and Bob Learn Secure Coding.“And the reason I wrote it was because past me, past software developer Tanya, who went to school in the 90s. I made every single mistake that I tell people not to do.

Tanya : [2:57] And after I made my first book, “Alice and Bob Learn Application Security,” I started teaching secure coding. And I ended up starting an academy and then a second academy because apparently I can’t help myself, Jamie. And I started just training, essentially, thousands of software developers how to write more secure code. And I just kept developing more and more training. And I was like, “I think a book is in order. I think I need to cover a lot more than I have been covering because…”

Tanya : [3:26] So companies would come to me and say, “we want secure coding, but could you deep dive into React or Python or Flask or whatever. Or .NET?” And I didn’t, I would have maybe an hour of content. But what if, you know, you want to make a secure coding guideline for a language or you just want to do an entire day on a framework? Or what if you’re working in embedded low-level systems, right? And it turns out there’s not a lot of training that is like that. And so as I was developing these sorts of things I’m like, “I just… I need to write another book. That’s what I need to do.” And then I have the excuse to do tons, and tons, and tons of research and share it.

Tanya : [4:08] And yeah so if and when you read the book listeners, don’t feel bad if you’re like, “oh no, I’m doing the thing Tanya says not to do.” I did all the things, Jamie. I was so guilty.

Jamie : [4:23] I think we all do, don’t we?

Tanya : [4:25] Well, that’s how we’re taught. From the very first lesson of “Hello, World” they teach us to make insecure code. So the first thing with “Hello, World” is how to output to the screen. That is fine. But the second part of “Hello, World” is: you ask them their name, you take their name. you don’t validate it, and then you say “Hello,” and you reflect their name back onto the screen with no output encoding. And then you just made cross-site scripting. And right from the very first lesson, we teach everyone wrong in pretty much every language, and so as a result we end up with a lot of people doing code the wrong way. Like, universities are still teaching lots of things wrong. And so I’m hoping that this book will help.

Jamie : [5:10] I mean I’m sure it will. One of the many things that I think helps people to get started, and this is… I have a bit of a crusade about never accepting the defaults, and I’m not the only person who said this The great Abel Wang said this “never accept the defaults.” Because the defaults are there to help you get started they’re not necessarily there to help you build the most secure thing ever. And whenever I see that someone has gone, “cool, I’ll do the equivalent of the tutorial, the hello world, and then push to production.” I’m like, “oh, no, no, no, no, no, no, don’t do that. Please don’t do that.”

Tanya : [5:51] In the book, actually, I have a big section about secure defaults and building paved roads. And in it, I’m like, “I know this is manipulative, but what if we manipulate our users for good? What if all the defaults are super secure?” Most users aren’t going to change the default and we can trick them into being more safe. Come on, let’s do it.

Jamie : [6:15] Yep. It’s the same thing with like seatbelts, right? Just by putting them in the car rather than charging people for them, which apparently some car manufacturers used to do back in the day, by just putting them there, making them the default. You make everyone more safe.

Tanya : [6:31] Oh, definitely, Jamie. Yes, there’s a lot of companies that charge for multi-factor authentication, or more often, they charge for single sign-on.

Jamie : [6:41] Right. That is crazy. Like, you want me to pay you more to make it more secure? That just doesn’t make sense.

Tanya : [6:52] You might be surprised by actually, I was speaking to the CISO of Semgrep about it, and he’s firm on, “we will never charge extra for that.” Because as a CISO, he’s like, “do you understand, sometimes it’s quadruple the price for the same product, only for SSO?” And he’s like, “as the CISO, I see this for so many different products.” And he’s like, “it makes me very frustrated because I need to keep all my people safe. " And then they’re like, “cool, 4x the price, twice the price, you know, an extra bump in price per month.” It’s just, yeah, it’s very frustrating.

Tanya : [7:25] And I’ve worked on dev teams that have made SSO, and I know that it’s extra work, and I understand. But I’m very frustrated at the idea of a security feature costing more.

Jamie : [7:37] That’s daft.

Tanya : [7:38] Unless the product is the security feature. Right yeah like if you buy Okta for the sole reason to have it, to [do] authentication and authorization for your product, of course you must pay for their product. But mean, like, if you’re buying an academy platform and they’re like, “cool. Like you can have general login for this price, but if you want to secure your login to cost more.” God, come on guys.

Jamie : [8:02] I mean, I don’t want to make a comparison to the Mafia, but i just did. I think that seems very much like, “hey, your app is really nice. Wouldn’t it be a shame if…” That’s my own personal opinion, and it is a silly joke but that’s what it feels like.

Tanya : [8:22] You need insurance for your users.

Jamie : [8:26] Okay. So you’ve taken all of this learning that you used to give out on these training courses, where you maybe would have a couple of hours to impress upon some folks, “hey, please do this this way because it will make it more secure. " And you’ve put that into a book and cause like… what was it, that I was talking to someone very recently and he said, “my apps are the most secure web apps ever.” And I was like, “oh cool. What did you do to do it?” And he said, “well I put HTTPS in front of it that’s all you do, right?”

Tanya : [9:05] Oh my gosh have this meme that I share sometimes, and someone on reddit asked, “what screams insecurity?” And a guy answered, “HTTP.” And it does definitely help with one of the many aspects of security, but there’s so many more. Oh my gosh. I want that person in your past to read my new book.

Jamie : [9:28] I will send a copy over to them. Oh my goodness.

Jamie : [9:33] Wow. Okay. So I am a coder. I’m going to write some code, but obviously a lot of the people listening to this will be .NET devs, but I’m writing some code. Are there any really quick wins that I can get? I mean, you kind of mentioned one earlier on about validating before just echoing their content back to the user, but if someone’s listening into this and they want one thing they can do today to make an app that they are building just a little bit more secure, or make the code that they are writing just a little bit more secure, what’s the quickest win?

Tanya : [10:06] The quickest win is to use a modern framework, and use the latest version of it. And then use the security features that are in it instead of writing your own. I realise that’s more than one thing, but they’re all sort of interrelated, so hopefully we can count it as one thing.

Jamie : [10:24] I mean, I count it as one thing, that makes perfect sense.

Tanya : [10:27] Another really really big thing they could do is follow a secure system development life cycle. So that means adding security steps every single time you build software. And I talk about that all the time. But yeah, if you add one or two, or hopefully five or more, because there’s five or more steps in most SDLCs, but if you add a security step to each phase, you’ll build way better software. And that is a whole bunch of activities, right? It’s not really one thing, but if your organization adds it to the way you build software, every single time you’ll release better software. As opposed to if you just do one-off things as one individual dev. But I give a lot of things that each person can do that make a difference.

Jamie : [11:20] Sure, sure. I guess maybe it’s not the best metaphor or comparison to make: when NASA are building a space rocket, they’re not going to check that it doesn’t explode just before they put the people in it, right? They’re going to make sure that it is safe at all steps along the way. That’s a really terrible example. I feel like most people probably don’t write NASA level code. Let’s pretend that everybody does, right? Is that a good analogy? You want to be testing for checking security things as you’re working through the process of building and designing and all that kind of stuff, right?

Tanya : [12:03] Ideally, the very first day of the project that you, like when you have that meeting where you do the kick-off where everyone kind of meets each other and you’re like, “hey, it’s official. We’re doing this project. These are the people on the project team. This is kind of what we’re doing.” If security could be there to introduce themselves and say like, “hey, I’m Tanya from security. I come in peace. And I’m hoping we’ll do these things as part of the project. You know, I’ll be here to answer questions the whole time. This is my contact info. I am your human that will help you with security. I’ve got you.” Right? Like if we start every project like that, and as we do each part, we continue to include security.

Tanya : [12:45] So literally as you’re coding now, so Jamie, when I wrote my first book, there was like one or two IDE security plugins, but now there’s tons. And so even just like as you’re coding and you tab off a line, you could have it do little red squigglies that tell you, “hey, you know, you used this function, we think you should use that function instead because it’s more secure,” or “that old function’s broken,” or whatever right? Like, there’s so many cool tools that you can use as you’re coding.

Tanya : [13:18] Right when you check your code in, you could have it scan your code like your whole repo every single week. Like, there’s so many different tools now which is exciting but also overwhelming .

Jamie : [13:30] Yes. Yep.

Tanya : [13:30] I go over a lot of the different types of tools and when to use them in the book. And I talk a lot about choosing whatever is best for each individual dev. So for instance, I had dinner when I was in Austin a couple weeks ago with a bunch of awesome humans. And one of them was saying, “yeah, my devs get too confused if it’s kind of correcting them as they’re coding. They find that overwhelming, and it also slows down their IDE a little bit.” And they do embedded, very fast, like real-time types of systems. He’s like, “I can’t handle that. So what we do is: once a day we flip it on, and we’ll do a scan, we fix our things, and then that’s it.” And he’s like, “but we don’t like to run it all the time because they feel like it interrupts their flow.” And I’m like, “yeah whatever you’re doing is perfect.” Right? Like if it works for you and you’re using the security tools and you’re fixing bugs, you’re amazing. But in my books.

Tanya : [14:38] So I feel like, One of the important things is figuring out what works for you and your team, because there’s no one tool that’s great for, and I work at a tool company, right? There’s no one tool that’s perfect for every team. Don’t tell my sales team that. But like, there are tools that are wildly popular that are super amazing, but might not work for your organization because you’re building hardware. And so you have to do waterfall and you need to go really slow. Or maybe you’re doing a hundred releases a day. Do you know what I mean? And those two teams probably don’t want to use the same tool set and that’s okay.

Tanya : [15:20] So yeah, I think it’s really important to find things that work the way your team work, that work with the tools your team already likes to use.

Jamie : [15:30] 100%. It’s the same when it comes down to IDEs of choice. And, you know, perhaps if you use a specific linter or a specific rule set for things, right? Or even if you want to go from a process point of view, right, the parts of Agile that work for your business are the parts of Agile that work. Not all of it may work. Or the parts of Scrum or insert the name of some process here, right? You have to pick the tool that works for you.

Tanya : [15:58] Yes. Well, and here’s the thing, Jamie, is that as the AppSec person, because I worked full time in AppSec for quite a while, and then I started doing a lot of consulting, and coming in as a consultant, you don’t get to pick the tools, or you don’t usually. And just so many places I’ve gone into work, and someone from the AppSec team or sometimes the CISO, they decided, “oh, okay, so we’re going to use this tool.” They didn’t ask any of the developer teams. They didn’t see how the devs work. They didn’t let them try it out. And then it’s just like, imagine a very enthusiastic child petting a cat backwards. Very, very backwards. And the cat’s just like, [growls]. And that’s how it is all day there. Because the tool just is conflicting with the way they like to work. It doesn’t work with their tools. It’s slowing them down. And it’s just, it’s not killing them, but it’s really annoying, and frustrating, and causing friction between the teams. And so sometimes I’ve been able to swap out tools or tune tools and make them better or find new ways to use them. But sometimes I’m just like, “we need to throw this in the garbage and get something new. Everyone’s angry. It’s hard to do my job if everyone’s angry. Like we can do better.”

Tanya : [17:20] So yeah, I agree with you.

Jamie : [17:23] So then obviously, I realise… So I’m talking to Tanya-the-person hopefully, not Tanya-the-Semgrep-person, but like how do you learn about all of these tools? Like is there a central repository that you can go, “oh cool. All of these tools exist.” Or is there like a, I’m kind of hinting at Owasp here… but like is there a central place that you can go to learn about them? Or is it more a case of just meet lots of people and see what they have to say?

Tanya : [17:52] So it’s all of those things. So if you go to Owasp.org, it is a ginormous website with tons and tons of amazing information. And they have a page for every single type of static analysis tool, every type of dynamic analysis tool. They have lists, and lists of tools. And knowing that they exist and then you can go visit their webpage is very helpful.

Tanya : [18:16] However, I don’t know about you, Jamie, but whenever I read the marketing stuff that is on the website for most of these tools, I’m like, “I still don’t know what you do. Like, is this a DAST or a SAST? Is this an IAS? Like, what have you made?” And a lot of them are like, “we don’t like labels.” And I’m like, “well, I don’t like writing cheques for things I don’t understand. So we have an impasse here, okay?” And I wish websites would just say, like, “we scan your code for vulnerabilities,” or “we scan third-party code for vulnerabilities,” or you know “we’ll dynamically interact with your app, and test it, and find vulnerabilities,” right? Like, what are you going to do? And how are you going to do it? Where do I put this in my SDLC? That’s what I want to know as a more nerdy person.

Tanya : [19:05] And so Owasp has lists that’s good. In my book, I explain what each one does. I also have…

Tanya : [19:13] So I have a free academy now. So last year, Jamie, I don’t know if I told you. So Semgrep bought my little company, WeHack Purple, and we took WeHack Purple Academy. We made the entire thing free, and rebranded it, and then added new courses. And so there’s a course called “Application Security Foundations Level 1”, and all the courses are free, including this one. And I literally just go over every single type of tool, and when you would want to use it, and how you would want to use it. And I don’t talk about products. I talk about the categories of tools. So what is a Web App Firewall? How does that work? Why would you want to use one? When is it awesome? When maybe is it not awesome? Can you use it instead of writing good code? No. Et cetera.

Tanya : [20:03] And so I made that because it took me so long to figure out what all the different tools do. And to be quite honest there’s such a huge difference in, not just like, the different tool categories but I mean just from vendor to vendor. And so if you are listening and you’re like, “I have to go buy one of X type of tool,” look on the internet for sure. But I like to ask friends who also work in AppSec or who are also devs, like, “hey, what do you use? Do you like it? Does it cause frustration a lot? Do you want to throw it out the window? Or are you like, this is my valuable tool that I hope no one ever takes it away from me,” right? And if you ask a lot of people, then hopefully you can get sort of like a short list that you want to try out. And then definitely try the tools with your tool set. So for instance, if it has an IDE plugin, plug it into your IDE, play around with it.

Tanya : [21:04] And especially, Jamie, a thing I did not know when I started. So there are a bunch of intentionally vulnerable web apps out there, which I learned on. I learned to do pen testing on stuff like Juice Shop. Juice Shop’s amazing from OWASP. There’s a whole bunch of them that are really cool. However, vendors test their stuff against them.

Tanya : [21:27] And I have since learned some vendors will hard code to ensure they find the vulns that are supposed to be there. And so they are non-accurate tests as to how well a tool works because all the vendors have the answer. And they’re not supposed to hard code, but some of them do. And I haven’t actually seen it myself, but I’ve had a bunch of clients that have explained tests they’ve done that prove that… or it very much so appears as though they have hard-coded the answers in. And so instead, what I would do is if you’ve had a pen test done and they found a bunch of bugs, awesome. Keep a copy of the buggy version and that report, and then run all the tests on that, and see if it finds the things your pen tester found. I find that to be a little more accurate.

Jamie : [22:16] Yeah, that’s a good idea. Almost like a second opinion, but not really a second opinion, right?

Tanya : [22:23] Yeah. Yeah, I like that. I feel like there’s a lot of marketing and a lot of promises on the internet. And what actually matters is your team writing better code and your team not wanting to murder the security team. And so, yeah, like even if a tool is like really, really popular, if your team, it just doesn’t work for you, there’s nothing wrong with your team, right? It’s just not a good fit. And that’s okay.

Jamie : [22:51] Yeah, and like you said, the sort of understanding the fundamentals and writing the secure code to start with, right, that will get you through any kind of test, penetration test or security test faster than submitting some code, reading through the report, and then going, “oh, cool, we have to change these things. I’ll go change these things.” Then submitting the code again. Because if you’re already doing the secure things to start with, you skip that first load of testing, right?

Tanya : [23:19] Exactly, Jamie. It’s funny because sometimes companies, they’ll talk to me about training, because I still do training all the time on the side from my full-time job, because I don’t know why. Anyway, but one of the big benefits of training is that you just like don’t make lots of obvious bugs any more. And so then you just find fewer vulnerabilities because they don’t exist any more. And then also because you had this training, not just one person, but a whole bunch of people, then you talk about it. And then as a culture, you tend to change.

Tanya : [23:55] And it’s funny because like lots of my clients will write me six months later and be like, “we now have an application security policy. And we now have a secure coding guideline. And we now have this and that, just like we talked about.” And I’m like, “yes!” Because it’s not like the day that the trainer’s there that you’re really, like that is what you’re charged for. But like the value you get is usually like three, six, 12 months down the road as you just see fewer bugs being created, better designs happening, people speaking more openly about security. And culture change is a hard thing to do. And I don’t know about you, Jamie, but like if the security team that’s internal says, “hey, we have to do this now,” some people listen. But if an external contractor comes, well, they’re an expert. We should definitely listen to her.

Tanya : [24:51] And I was an employee in the government for like 13 and a half years in Canada. And like, I would get so annoyed. I’m like, “I have been saying that for six months. The consultant says it once. And you’re like, why didn’t you tell me this, Tanya?” But I will use that power for good whenever I can.

Jamie : [25:10] Yep. Yep. I remember at a previous job, what I did was I ran a lunch and learn, a series of lunch and learns. I’d go ahead and learn a little bit about HTTP headers and the recommended secure headers that Owasp recommend… “the recommended headers that they recommend,” that’s a bad sentence but we’re leaving it in. And what I did was, you know, a whole bunch of different sessions about, “okay this is what Content-Security-Policy is. We’re not going to talk about how to implement it, we’re just going to talk about the fact that it is an allowlist for sources on your app. And then I’m going to talk about what an allowlist is and what a denylist is. And then you’re going to go away and figure out how to implement it in your app, because you’re going to spend a week doing it, because Content-Security-Policy is hard.” And then you know, the first one I had like five, 10 people; the next one I had 12 people; the next one I had 13 people because there were folks who wanted to know this stuff right.

Tanya : [26:14] Oh, it’s amazing. It’s amazing. And you made something for .NET about security headers didn’t you?

Jamie : [26:22] I did. I did. Yeah. On the back of that, I figured, “hey, I could try and be a bit of a force multiplier.” And I created it. There’s a NuGet package that I created called OwaspHeaders.Core. And the idea is that I’m trying to make it as easy as possible to implement those Owasp recommended security headers. The one thing it doesn’t do for you automatically and easily is Content-Security-Policy, because like I said, Content-Security-Policy is tough. But once you’ve added it, it’s a one-line change, and you get all of… almost all of the good ones. Sorry, almost all of the recommended ones for free right. And so that’s why I’m trying to make it, “hey, look,” like, you said right, “let’s make the defaults secure defaults. Because then once you do that, you lower that barrier to entry. It becomes super easy right.”

Tanya : [27:15] Yes. Exactly. Exactly, exactly. I think that I recommend your NuGet package in the book, too. Because I know that I was aware of it. I’m pretty sure that I talk about it in the book, but now I forget because I wrote chapter seven quite a while ago.

Jamie : [27:32] That’s the thing with writing books right, they take so long to do.

Tanya : [27:37] Yes It it has been a two and a half year journey and although I love writing I do not love edits. My technical editors have been a complete dream. This time, they’re really, really wonderful humans that kept kind of cheering me on, helping me make the book better. And I chose a dev and then two AppSec people so that I could have both sides of the equation, if that makes sense, because I want to make sure that devs liked it and that their opinion was represented. And I was a dev for 17 years professionally, and then I coded for two years before that. And then I’ve done security, I think, for 10 or 11 years now. It’s been a while. And so I have more dev experience than security experience still.

Tanya : [28:30] But it’s older experience and I’m like, “maybe I think like a dev still. But maybe I’m wrong.” Do you know what I mean? So, yeah. Anyway I appreciate you for writing a thing that helped lots of people, because security headers are awesome and everyone should use them.

Jamie : [28:47] Thank you very much Tanya, that’s that’s very kind of you to say that.

Jamie : [28:52] But the way I figured it was: I can do a little bit of tough, you know, a little bit of the hard work behind the scenes to set these defaults, and then it’s a single line right ,and then everybody can use it. And then everybody’s more secure by default. It’s the same thing with like okay so let’s really quickly talk about SQL injection because it’s always one of the big things right. SQL injection, it’s so easy to protect against. But so many people don’t. Like, it’s always at the top of the, it’s not the top of the list, but it’s always in Owasp’s top 10. Like, and that is just, it boggles my mind. It boggles my mind.

Tanya : [29:31] Yes, I agree. I, so I have a chapter on vulnerabilities and I go through vulnerability categories and I don’t cover the Owasp top 10 because I already covered it. And it’s, it’s kind of done to death. And I also feel like there’s not 10 things. There’s way more than 10 things. And so I did things differently, but I talked about injection. But the rest of the book is, “this is what you do to write amazing code.” And so then when we got to the part where I talk about injections… I’m going to talk about all the injections, like command injection, LDAP, et cetera. There’s many different ways that you can trick a piece of software into executing your code. Right that is generally malicious if you’re doing that And in it I’m just like, “you already know how to defend against this right? You validate your inputs and then if you have to accept special, potentially damaging, characters you either sanitize them out or you escape them, and then you use parameterized queries. And if you do that you’re awesome. That’s it that’s all you need to do.” I’m like, “you already know this like the back of your hand.” By the time you get to chapter eight you’re like, “whatever.”

Tanya : [30:46] I wanted to focus on the idea of: if I teach you how to do the right thing, I don’t need to get you to memorize a ton of vulnerabilities. Because if you learn specific defences for specific vulnerabilities, you’ll spend forever doing that, like whack-a-mole, right? Versus if you learn all the main important defences, almost all the vulnerabilities don’t apply it to you any more, if that makes sense. And I wanted to make everything as easy as possible. So I have a whole bunch of cheat sheets. And I’m developing more once the book is done. So I’m going to make it basically where you can go to my little newsletter page and just download lots of them. So in the book, I have three listed. But surprise, when you get there, there’s going to be more. And so I have a security header cheat sheet where it’s like, “this is how you configure each one of them,” especially Content-Security-Policy header.

Tanya : [31:40] Especially with all the new developments like Trusted Types. And other things you can do to, you know, avoid having to use a nonce all the time, because that really got complicated and broke a lot of sites. So they’ve come up with better things that they can do to make sure Content-Security-Policy works for you. And so I talk about it in the book, but then I’m like, “you can just copy and paste the actual code into your app from the cheat sheet. So you don’t like you do not have to think hard.”

Tanya : [32:08] And then I have one for error handling, etc. Because the easier we make it for them, the more likely it is they’ll do it. And I feel like devs have… not a trillion, but many, many, many priorities. Like they’re supposed to be full stack, and know tons of different languages, and be great at UX, and also do really fast apps ,and also be security experts and, and, and. And like, if we can make security less of a difficult lift, we’re more likely to get what we want, I think.

Jamie : [32:44] Oh, definitely, definitely. The easier it is to do something, and in fact, if you can do something without having to think about it, then, you know, you’ve won already, right? Like you said earlier on, one of the easiest wins you can get is use a modern version of some kind of framework and work within the security practices there. Because the authors of that framework have already thought about this kind of thing they’ve already come up with maybe sensible defaults that are secure. Or perhaps they’ve already had their framework tested, right? In the world of .NET, I would be very surprised if Microsoft aren’t running a whole bunch of security tests on their code. In fact, it’s open source folks you can go read it yourself; they are doing a whole bunch of security tests for you, right. It’s not that you can’t write in secure code with .NET languages. It’s just they’re already providing that base level for you. So just join in and use what’s there, right?

Tanya : [33:45] There are so many amazing security features in .NET. There’s so many. Like, because I… I wrote about eight different frameworks and .NET by far had the absolute most different security features. And part of it, some of them are from Windows. Some of them are from C… because I wrote about C# and .NET. And to be quite honest, audience, I mixed them up quite a bit because, “what is specifically C#, and what is specifically .NET,” got a bit confused in my brain. But I’m like, all of it’s good. Do all of it.

Tanya : [34:22] And like a lot of us that are programming using .NET, we’re using C# as opposed to VB now, which is fine. And VB is still cool, kind of. Anyway, I’ve programmed way more on VB .NET, but I digress. So I feel like, if anything, the .NET framework really spoils us with so many different things to help us. And yeah, so I used to work at Microsoft, and one of the things that I absolutely loved, and one of the reasons I really wanted to join Microsoft was because security is a huge priority for their entire organization. Like I remember saying to some people on my team, “oh, we need to do this because it’ll make it more secure.” And I started like justifying why we needed to do something. And they’re like, “Tanya, it’s security. Of course we have to do it.” And I was so used to having like a many-week battle for everything I wanted. And they’re just like, “of course, just tell us how.” I was just like, “oh my gosh, swoon.” Yeah, it was really, really nice.

Jamie : [35:28] Nice. yeah making that secure by default and having that culture guess, that cares about security. Now, I’m not going to say who but there are some companies I’ve worked for in the past who have seen—oh my goodness do you remember The Phoenix Project?

Tanya : [35:48] Oh yeah.

Jamie : [35:51] There’s the security person in that, I think it was the CISO and everyone saw that person as the villain. Like, I’ve worked at places that are like that. And it’s like, “no no,” like you said earlier on the security person is a human they are your friend they want to help you succeed.

Tanya : [36:09] I have to say, to be really super honest, Jamie, and this is probably going to sound really bad, but I have found when working in AppSec, quite often, I will war with the rest of the security team on behalf of the devs. And I’ve been asked many times, “are you on our team or theirs?” Because the enterprise security folks will make a bunch of decisions because they want to protect our organization. And I’m like, “listen, I need compromises because of this. And we could do this to try to mitigate that risk. And we could do that.” And they’re just like, “no, this.” And I’m like, “devs aren’t like everyone else. Okay. Yes, they can’t have admin privileges everywhere and run around with no safety net. I agree. But we do have to give them the flexibility to create amazing applications, right? So we have to do something for them.” And it’s really hard if you’re working with people that don’t understand AppSec and aren’t open-minded to maybe thinking a bit outside the box of how you can solve some problems. And usually I can get somewhere with them, but sometimes I can’t.

Tanya : [37:31] So I’m very biased. This is my side of the story, right? So take what I say with a grain of salt. But I’ve worked at quite a few places, Jamie, where we have a bunch of legacy stuff. It’s a thousand years old. It has a trillion vulnerabilities in it. And I’ll talk the devs into opening some of those up. And I’m like, “listen, can you just fix the, ‘oh my gosh, I’m going to cry’ level vulnerabilities? Like there’s injection in here. I know this app is old, but it’s causing huge business risk. Could you just fix injection in the old apps in the next six months?” Right. And then we would go to release them. And I’ve had this happen at more than one place that I’ve worked.

Tanya : [38:13] And the other security people are like, “you can’t release that to prod because there’s still high and critical vulnerabilities in it.” So let’s say it has 20 vulnerabilities when we start and then we fix the three scariest ones and we want to go to prod. They’re like, “I’m not letting you put 17 high vulnerabilities into prod.” I’m like, “no, they’re already there. What I’m doing is removing three.” And they’re like, “high vulnerabilities don’t go to prod on my watch, Tanya.” I’m like, “they’re already there on your watch, okay. Let me fix three of them.”

Tanya : [38:44] And I worked at one place where I thought things were going to prod, I was doing all the steps. And the nit turned out that one of the other security people had blocked over 100 of my fixes. And yeah, I was really angry and when I found out because I just assumed I did all the steps, and like I had all these approvals, and he had like last minute stopped a bunch of them. And I hadn’t realized because I’m doing AppSec and I’m all heads down on everything, right? I’m just like, “oh, I just assume if it was all approved to go that it went.” And so then I run a scan and I’m like, “wait, what’s happening? Why is this still here?” Right?

Tanya : [39:24] And they’re just like, “how can you be so grossly irresponsible, Tanya, releasing criticals into prod? " I’m like, “what are you talking about? " And reducing organizational risk, and just having this impasse over, and over again with people. And like this is my viewpoint right this… And clearly I couldn’t get my message across clearly enough, if they still kept blocking things right. Like they didn’t see a reduction, they saw Tanya’s being grossly… I remember one of them saying like, “this is gross negligence that you would release this.” And I was like, “that’s funny I was thinking the same thing about you.” That conversation didn’t end well.

Tanya : [40:03] Yeah. So I feel like, you know what, to be honest, Jamie, though, I feel like a lot of this comes from emotional insecurity. So if you don’t understand something, sometimes… so when humans feel insecure, that’s when a lot of our ugliest behaviour comes out, right? Like when we’re really frustrated or we feel insecure, we behave or we’re afraid, we behave not awesome. And some of us focus that internally. So when I feel insecure about something at work, “I’m like, I’m going to go learn that inside and out until I feel super confident.” And that’s one of the ways that I deal when I feel insecure. Whereas what some other people will do is they’re like, “I’m going to yell at everyone,” or “I’m going to, you know, just avoid that at all costs.” And so as a result, I think that that’s where a lot of those conversations come from. It’s, “I don’t understand, so I’m going to yell until Tanya stops bugging me.”

Tanya : [41:06] Not awesome on my side of things. But anyway, sorry for the rant.

Jamie : [41:12] No, I appreciated that because it’s an important lesson, right? We as professionals, regardless of whether we’re development professionals, security professionals, whatever it is, right? We need to remember that at the end of the day, we’re still dealing with humans, right? We still have to work alongside of people, right? And so those interpersonal skills of being able to go, “actually, what is it that you’re trying to tell me here, Tanya?” Rather than going, “no, I’m going to dig my heels in because I’m scared about what you’re doing.” I need to go, “right, Tanya, what is it that you’re doing and how can I understand it better?”

Jamie : [41:48] And I went to a brilliant talk last year. It was a cyber security conference in my area. And there were a whole bunch, every single talk was brilliant. It was one day, one track, six talks. And I think it was the fourth or fifth talk in: the chap stepped forward and said, “I can produce you a list of CVEs with high, medium, and low criticality. But that actual data is pointless, because I could produce a list of CVEs for your app where all of the high priority ones they’re listed as high priority because they’ve been categorized that way, but none of them are actually relevant to either your application or the way that your users use that application, right?

Jamie : [42:31] And it’s about figuring out the context behind them And so, like you, said right: here’s a list of extremely high priority, “they’re going to make me cry” CVEs that have been found in the system, that are relevant to how the user uses them. Go fix them please. And it sounded like the other security people you were talking to were like… well because you said quite literally, “hey yeah. You may have fixed seven of them but there’s still 13 of them.” But then, you know, you’re saying, “yes but there were 20 to begin with, and they’re there live now can go and actually do it now,” right. And it’s all about that context. We always have to remember the context of everything we do, I guess , and the fact that we’re dealing with other people, and then maybe try and put that across

Jamie : [43:20] I’m not saying you didn’t do that, I’m just saying that, you know, if I’m at work and somebody comes to me and says, “hey I’ll fix this thing.” Awesome, let’s have a look, what is the context for this? Oh you’re fixing the thing, right. Not that you’re intentionally introducing something. I don’t know that’s just my two cents of what you were saying.

Tanya : [43:37] To be honest Jamie, when I switched to security I had to work so hard on my soft skills. I thought it would only be technical skills that I had to work really hard on, but I had to learn to be more persuasive. I had to learn to negotiate more. I had to learn to deal with…

Tanya : [43:59] So this might sound weird, but as a dev, I mostly spoke to other devs, and we all speak the same language, right? Like, I’m like, “you test this, I’ll do that.” They’re like, “cool.” I’m like, “my object does this. Does your object do that?” Cool, right? But then when I worked in security, I was like, “I have to learn how to communicate well with the other security folks. I have to learn how to communicate well up to management, especially about things that they’re quite afraid of. And then I had to learn how to communicate the new things that I learned to devs.” Because it’s like, “OK, I have all this knowledge that they don’t have, but they’re still brilliant.” Right. But like, for instance, lots of security folks will say, “oh, your session ID should be ephemeral,” which means short lived. No one can code a thing that’s short lived. That’s super vague. Right. Because for you, short lived might be two minutes. But for me, that might be two weeks. Right. We’re not going to get a good design if we use vague words. And also ephemeral. I had to look it up the first time. I’m like, “what the heck does that mean? Why can’t you just speak English to me or dev?”

Tanya : [45:10] And so, yeah, I still have to work sometimes on my soft skills of how to deliver really tough messages. I met with a client earlier this week, and they were struggling to communicate to their board their risk posture. And their board was like, “we’re scared about security. We don’t think we’re in a good enough spot.” And the AppSec team’s like, “actually, we’re rocking it. But we don’t know how to show that to them.”" They’re like, “there’s still vulnerabilities in the backlog. We’re a failure.” And they’re like, “no, those vulnerabilities don’t like actually represent serious business risk.” And they’re like, “why?” And they’re like, “because.” And that’s not a good enough answer for the board. So they’re like, “how do we express this in a way, especially like with graphs or numbers or whatever, like how we look compared to other financial institutions, et cetera, right?” And so we had like this whole one hour session, like to plan how they would communicate to the board effectively, “don’t worry, we’ve got this.” Which to be quite blunt, Jamie, is super rare, right?

Tanya : [46:11] Usually I’m helping them craft a message that’s like, “we don’t got this. We have like serious risk that’s not being addressed. We need more resources. We need, you know, buy-in from these teams,” or whatever it is. Right. And like, we’re trying to persuade the board and other teams into something. This is the first time I’ve got to do the, “don’t worry. We’re cool message. " I’m like, “whoa, what a treat.”

A Request To You All

If you're enjoying this show, would you mind sharing it with a colleague? Check your podcatcher for a link to show notes, which has an embedded player within it and a transcription and all that stuff, and share that link with them. I'd really appreciate it if you could indeed share the show.

But if you'd like other ways to support it, you could:

  • Leave a rating or review on your podcatcher of choice
  • Consider buying the show a coffee
    • The BuyMeACoffee link is available on each episode's show notes page
    • This is a one-off financial support option
  • Become a patron
    • This is a monthly subscription-based financial support option
    • And a link to that is included on each episode's show notes page as well

I would love it if you would share the show with a friend or colleague or leave a rating or review. The other options are completely up to you, and are not required at all to continue enjoying the show.

Anyway, let's get back to it.

Jamie : [46:37] Oh my goodness. So, yeah, I think what I’m taking from what we’ve just been talking about just now is that as much as, like you said, as much as the technical skills are required, you need to know about certain things, and be able to make your code secure by default, and things like that. It’s being able to communicate that to other people, to the shareholders, to the stock… whomever. Whoever is making those decisions that, you know, like you said, “it’s cool. We’ve got this. And here is why,” or, “the ship is on fire, and the sky is falling, and here is why.” Because I think…

Tanya : [47:13] Yes.

Jamie : [47:13] Because like you can’t just step forward and say, “we need five more engineers to help with security full stop.” You know, because you’re going to be asked, “well why do you need that many engineers? " or “can we get away with three? Can we perhaps go with four? We don’t quite have the budget right now, perhaps we can get a consultant in,” you know that kind of thing. Or, “is there not just a tool you can run that will fix it?” Right, because you need to, again it’s that context, you need the context.

Tanya : [47:41] Yes. And and the ability. Yeah, I had to work really hard on this. I also learned about um like types of metrics to gather and then how to, interpret those metrics so that people actually understand what the heck they mean because giving like this big graph to a bunch of executives, it isn’t enough. You have to tell the story of the data. And yeah, and this is the same when I talk to developers about secure coding, or there’s like a special part for data scientists in the book, because so a couple of times I’ve been hired to train just a giant group of data scientists. And they are like the gunslingers of software development, Jamie. They are like the wild west. There’s no SDLC. Why on earth would they use version control? Boom, boom, shoot from the hip. Let’s take scripts directly from our customers and execute them against production databases. YOLO.

Tanya : [48:45] And trying to explain to brilliant people, who are like very good at their job, that they need to spend a lot of extra time to do the same thing that they could do quickly. So I’m like, basically, I need us to go. So it’s not that I want us to go slower. It’s that I need them to take extra precautions, right? And trying to explain that to them when they’ve never had any software development experience or any training in the system development lifecycle, that is a conversation. Like and it… I’ve had a lot of things go really well where we redesign things, and it’s like, “let’s add multiple layers of shielding, and abstraction, and validation, so that by the time that thing gets to the database it’s really safe,” right. And we’re making sure you don’t return the entire database by accident or anything else that you should not. Like, I’m talking about like 100 data scientists all using the same dba account with dbo access to production database that handles billions of dollars; just all of them yoloing all day long. But we transformed them, it was so amazing Jamie.

Tanya : [50:13] So yeah, communication skills. I’m still working on it all the time. I’m still always reading books about how to express things better because you get more of what you want then.

Jamie : [50:24] Yeah, I agree. And to your point about the data scientists: I had a bit of a brief look into working alongside an academic recently.

Jamie : [50:36] A friend of mine is a PhD, and he was like, “I have this Python code. I have no idea what it does, but I ran it on my computer…” Like, I don’t know if you can hear my teeth curling, but that’s what happened. It was like, “why did you just run it?” And he’s like, “well, I found it on the internet, and it said that it will do what I want. But it didn’t do what I want.” I’m like, “dude. No. No. Why did you do this?”

Jamie : [51:05] So we had to go into full lockdown on his computer, and make sure there was nothing there that shouldn’t have been there. And then it was a case of, “right. Why didn’t it work? Oh, it didn’t work because it was Python 2 and you’re running Python 3 You need to be on Python 3, you don’t want to be on Python 2 So I’m gonna have to take some time and translate it to Python 3, and then we can run it.” And then it turned out that it wasn’t going to work anyway because some dependency was broken, and… argh. Yeah, so I can understand a little bit of where that comes from. It feels very much like those who are in that space: they have some code, it worked once, and we wrote it fast and it does what it does, and it will help us to solve the problem. And we don’t have to worry about it because security doesn’t exist because security doesn’t have to exist. Right.

Tanya : [51:54] Oh, Yes. Oh, my gosh. I talk a lot about in the book, like, don’t just take random things off the internet and run it. If you don’t understand it, and you put it into your app, you have no idea what extra things it could be doing or not doing. And same with code from the AI. It’s so funny. My publisher wrote me a message partway through writing the book and was like, “you’re not allowed to use ChatGPT to write your book.” And I’m like, “hey, it’s my book, not their book. I’m writing my book. This is the best part is the writing part.” ChatGPT can do my edits, which I wish it could. It can’t yet or it would be very wrong.

Tanya : [52:34] But I remember like looking up things, Jamie, and it was so bad. And so when I do trainings, I do this thing where I do, “bad code, better code, great code.” And so we do like a little lesson on like input validation or whatever, right? And then we look at some code. I’m like, “this code sucks. Why does it suck?” And then hopefully they answer a bunch of things we just learned aren’t there, right? So then I show more code and we walk through it. And I’m like, “this code’s better. Why is it better?” And then, you know, some of the things are there. And I’m like, “this is the best code. Why is this code awesome?”

Tanya : [53:06] And so I literally just go to ChatGPT and I’m like, “make code that does this.” And every time it’s terrible. And so I always start with that. And then I just go through all the things in my book. And I just, I start adding the things that I’ve been teaching, like to each screen and just adding like more and more security controls. And for listeners, a security control is just the part of your code that does a security thing. So like it logs the person in, it makes sure something’s encrypted, it validates that they’re allowed access to whatever that function is, whatever does the security feature.

Tanya : [53:43] And then by the end, I’m like, “this code’s amazing. Why is it amazing?” And they’re like, “whoa!” Or there’s this, there’s this, there’s this, right? And so as a result, it’s nice that ChatGPT essentially will make me tons and tons of terrible examples.

Tanya : [54:02] However, I’m hoping it’ll get better. And I just took this course from this guy named Jason Haddix about how to build your own security bots. And he gave us as part of the course a bunch of bots. And so his are all like, because he’s a red-teamer, pen-tester type of person, a lot of them are stuff like that. And so I want to make my own RAG server with all my books, and research. And a RAG server is… it’s a server where you put a whole bunch of data where you’re like, “this is right. Everything else is wrong. Like, always access this first. This is always correct compared to whatever else you know, ChatGPT. Please shush,” essentially.

Tanya : [54:44] And because, literally, it’s wrong all the time, Jamie. It is very wrong when you ask it secure coding things, it gives very, very poor advice. And so I want to do that so that then I can like write things faster, look up answers faster. Because I actually like look through my own books all the time when I forget syntax for things literally have like, I have my first book on my desk like for all the time to access it, or reference it. And so if I could set up like a RAG server and then… with all of my research and data, and then be like, “okay. So now make up a great example of code, improve this code for me.” I think that would be a really cool.

Jamie : [55:26] Yeah, yeah. I do feel as though—so my example is going to be way outdated—but I remember there was a discussion on meta stack overflow. So this is the bit of stack overflow that discusses stack overflow right. And they were talking about rules and things like that, and there was a whole conversation about, “what if someone posts malicious code as an answer to a question on stack overflow?” And the accepted response from the entire community in that section was, “if user A posts intentionally malicious code as an answer to a question by user B, it is on user B to ensure that that code is correct and doesn’t break their machine and doesn’t do anything it shouldn’t do, and isn’t malicious before they run it.” Like you said, right, you need to understand it friend of mind, Jim says, “trust, but verify,” right? And that’s, it’s super important to do that.

Tanya : [56:29] Jamie, I am banned for life from Stack Overflow because a few months ago… and I write for their blog, so it’s awkward, right?

Tanya : [56:41] So a few months ago, I’m like, “I’m going to answer 100% of all the Semgrep questions in one day”, because that’s what I’m like. I can’t do one or two. I’m just like, I guess whatever I was supposed to do that day was canceled. So I’m like, “I’m just going to answer all the questions on Reddit and on Stack Overflow.” And so some of the questions, so one in particular was, “hey, how do I suppress this result?” And I read their code, and then I read the result. I’m like, “yo, you do have cross-site scripting. So here’s the fix for your code.” And everyone’s like, “that’s not what he asked. He asked how to suppress this result. Downvote, downvote, downvote.” And then there was another one where I was like, I needed more information to answer the question. I’m like, “that’s why you’re not…” and then apparently you’re not supposed to do that as an answer, that’s supposed to be a comment. And then I’d put a link for more information in the documentation, so that they could get the syntax correctly, because again… and then they’re just like, “you put a link, you did this. They’re like, banned for life.” Oh, man.

Tanya : [57:42] Yeah. So I have to write them and ask to be unbanned, so that I can continue to be annoying on there. But this is why AI bots for moderation and stuff need to have some sort of second control. Because it’s like, “oh, actually, she’s walking around trying to put magical security dust on things. And people didn’t like me saying security-minded answers all the time,” right? Like, don’t suppress that. That’s a real result. Or, oh, here’s how you fix your code. Nope. Right? So I feel like…

Tanya : [58:16] Yeah. I love Stack Overflow and I use it a lot. It’s really important that you do not copy anything from it into your code unless you understand it, and you are sure you’re not copying a vulnerability. Because almost all the time, stuff that’s voted to the top has had all the security removed. And you would do better when you search to say, “how do you do blank securely?” And it’ll take you five minutes instead of one minute to find your answer. Or if you really want to like up the ante, just put “Owasp” in your search term. And I know that sounds weird, but you’ll just get tons, and tons of security focused answers about what you asked. And just by doing that, your code quality will go up immediately.

Jamie : [59:02] Yeah, absolutely. Absolutely. Because like you said, it’s about figuring out that… part of it is figuring out how to ask the question, right? I know we’re running out of time, so maybe maybe we’ll skip over this, perhaps come back to this another day. But yeah you’re absolutely right. It’s part of it is… part of it is learning how to ask that question, and how to give, “how do I make this…” I like that, “how do I make this more secure? “Not, “how do I,” in the in the example that you gave, “how do I suppress this warning,” that tells me that the person didn’t want to know that it wasn’t secure right. Especially from your answer where you were like, “hey, dude, you need to know about this, this error, this warning, because it’s telling you literally, you need to fix something. So the best way to suppress the error is to fix something.”

Tanya : [59:48] Yeah, that’ll solve it.

Jamie : [59:53] Excellent. So Tanya, I know that we’re running out of time and you’re a very, very busy person. So I wonder, I’ve already got a link for the book and I’m going to put that in the show notes. So folks click through, check out the book for sure. Because like I said, the app security book was brilliant. I’ve read a little bit of the secure coding book, and what I’ve read is brilliant. So you’re going to need to get that. But could you perhaps remind folks about the title of the book? Perhaps like, is it only available on Amazon or whatever? And then like are there any other resources you recommend folks check out that are like connected to the book or related in some way.

Tanya : [1:00:32] Absolutely. So the book is called Alice and Bob Learn Secure Coding, and if you go to my website shehackspurple.ca—Yes, I’m canadian, and yes I say, “aboot.” So if you go there and you click on Books, it has a list of every single place you can get it. So there’s various different Amazon sites. There’s Barnes & Noble, Indigo, but you can also order it directly from the publisher and they will ship it anywhere in the entire world for you. Like they’ll ship to Afghanistan.

Tanya : [1:01:04] And my first book, this might sound weird, but like a lot of people in Pakistan could not get copies of my book. I want people in Pakistan to write secure code, right? Win! I want everyone to be able to write secure code that wants to. And so yeah, you can get it directly from Wiley and they’ll ship it wherever on the planet you are, happily.

Tanya : [1:01:25] I would really love it if people would join my newsletter. So if you go to newsletter.shehackspurple.ca, I am going to be doing live streams like I did for the first book. And so what we’re doing… well, I say we, but it’s me and friends. So each month, starting a few months into 2025 to ensure everyone that pre-ordered the book has it, every single month I’m going to stream one chapter. And so I’m going to have a bunch of friends on that are experts on those topics, and we’re going to discuss it for two or three hours live and take audience questions. And then we’re going to answer all the questions in that chapter.

Tanya : [1:02:06] And then just like the first book, I’m going to save all of them to YouTube so that you can continue. So if you miss one or whatever, I’ve got you. And I did this with the first book, because I was quite upset that universities wouldn’t teach it. I figured if I made a textbook, that people would teach it. And they all offered me less than minimum wage as an adjunct professor to teach. And then they own all my content after. What a deal. So I said, “if it’s going to be practically for free, why not do it for free on my terms?” And so this way I got to interact with readers, which was so amazing. An excuse to spend time with super brilliant people, like Adam Shostack has said he’ll be on again. And I had Vandana Verma on. I had like just all these really amazing human beings on. And then I get to ask them about their expertise. And sometimes we disagree, which is super fun. Because usually like they’ll disagree, but then in the end we always agree. It’s funny.

Tanya : [1:03:04] But all those are free. And then also if you join my newsletter, I’m also giving away cheat sheets to various parts. So each month I want to start giving away a cheat sheet as well. So there’ll be like a React cheat sheet, an Angular cheat sheet, a JavaScript, a TypeScript, a .NET, a C#, et cetera. With the idea that, you can use those to make a secure coding guideline or security guidance where you work. And so basically like join my little book community, if that makes sense. There’s a lot more than just the physical book that you get. Also, there is an audio book and e-book coming too.

Jamie : [1:03:43] Nice. Nice. So you heard it. You may not have heard it here first, folks, but you heard it here. Or read it if you read the transcript. But yes.

Tanya : [1:03:56] Thank you so much, Jamie. This has been amazing. And I’m really excited to get to see you when I come to London in January.

Jamie : [1:04:03] Yes. Yes. That is something we are definitely going to do. Awesome. Awesome. Thank you ever so much, Tanya.

Tanya : [1:04:12] Thank you so much for having me. Anytime you want to have me back. I would love to.

Jamie : [1:04:17] I’ll hold you to that for sure.

Wrapping Up

Thank you for listening to this episode of The Modern .NET Show with me, Jamie Taylor. I’d like to thank this episode’s guest for graciously sharing their time, expertise, and knowledge with us.

Be sure to check out the show notes for a bunch of links to some of the stuff that we covered, and full transcription of the interview. The show notes, as always, can be found at the podcast's website, and there will be a link directly to them in your podcatcher.

And don’t forget to spread the word, leave a rating or review on your podcatcher of choice—head over to dotnetcore.show/review for ways to do that—reach out via our contact page, or join our discord server at dotnetcore.show/discord—all of which are linked in the show notes.

But above all, I hope you have a fantastic rest of your day, and I hope that I’ll see you again, next time for more .NET goodness.

I will see you again real soon. See you later folks.

Tanya’s Previous Appearances

Follow the show

You can find the show on any of these places