PostHole
Compose
Login
SE Radio 658: Tanya Janca on Secure Coding
Tanya Janca, author of Alice and Bob Learn Secure Coding, discusses secure coding and secure software development life cycle with SE Radio host Brijesh Ammanath. This session explores how integrating security into every phase of the SDLC helps prevent vulnerabilities from slipping into production. Tanya strongly recommends defining security requirements early, and discusses the importance of threat modeling during design, secure coding practices, testing strategies such as static, dynamic, and interactive application security testing (SAST, DAST and IAST), and the need for continuous monitoring and improvement after deployment. This episode is sponsored by Codegate.ai
Tanya Janca, author of Alice and Bob Learn Secure Coding, discusses secure coding and secure software development life cycle with host Brijesh Ammanath. This session explores how integrating security into every phase of the SDLC helps prevent vulnerabilities from slipping into production. Tanya strongly recommends defining security requirements early, and discusses the importance of threat modeling during design, secure coding practices, testing strategies such as static, dynamic, and interactive application security testing (SAST, DAST and IAST), and the need for continuous monitoring and improvement after deployment.
Show Notes
Related Episodes
Other References
- YouTube: SheHacksPurple
- Course – Building An Application Security Program – Application Security Foundations Level 1
Transcript
Transcript brought to you by IEEE Software magazine and IEEE Computer Society. This transcript was automatically generated. To suggest improvements in the text, please contact [email protected] and include the episode number.
Brijesh Ammanath 00:00:54 Welcome to SC Radio. I’m Bridjesh Ammanath and today our guest is Tanya Janca. Tanya is the author of Alice and Bob Learn Secure Coding, Alice and Bob Learn Application Security, and Cards Against AppSec. Over her 28-year IT career, she has won multiple awards, including OWASP Lifetime Distinguished Member, and Hacker of the Year Award, and is a prolific blogger. Tanya has trained thousands of software developers and IT security professionals via her online academies, SheHacksPurple and Semgrep Academy, and her live training programs. Today we are going to talk about how to integrate secure coding into the software development lifecycle. We have covered secure coding concepts in Episodes 475, 568, 541, and 514. Let’s get started with fundamentals. Tanya, what are some fundamental security concepts that you feel every developer should know?
Tanya Janca 00:01:50 I really want everyone to know the idea of “least privilege” — the idea that we only grant exactly what a user or a person needs, so they only have access or permissions, or they can only see or do the things they actually need to instead of just opening the door all the way when we don’t need to. Another concept that I think is really important is usable security. Making sure when we design secure concepts that they’re not terrible for the end user because users are really smart and tricky, and they will get around them. And so if we make our security features more pleasurable to experience, it’s a lot more likely that users will do what we want and make the secure choices. I could go on. I’m wondering how deep you’d like to go on this question?
Brijesh Ammanath 00:02:43 We’ll dig deeper into each of these principles or the concepts that you mentioned as we go through the podcast. For the immediate next question, I wanted to ask you about trust and why it’s critical to stop assuming trust in systems and data.
Tanya Janca 00:02:59 Yes. So usually what I do is I explain the concept of implied trust. So users, human beings, actually in general, we trust; we’re very trusting compared to other animals. So if you look at panthers if they see each other, they usually, they fight or they have a baby panther. And there are lots and lots of different animals and animal kingdom that just have zero trust. When they see another of their kind, they try to kill them. Whereas human beings, we’re very trusting and as a result, we have an amazing society, right? We’re able to travel all over the planet, I’m able to send you money and you’re able to go buy a thing and then mail it back to me, right? That’s incredible. And so when we design our systems, we tend to design them with implied trust. So for instance, we used to design our networks where someone would get onto our network, we would make sure they’re the right person and they are allowed there.
Tanya Janca 00:04:00 But then once they were on the network, they could go anywhere and do anything. And that assumed trust. It assumed that this person knows, oh, well I’m not a database administrator so I shouldn’t go on the database servers. When in fact it turns out not every person is trustworthy. And so we need to not trust any sort of input or connection or integration to any of our systems. So if we’re getting input from a user, whether it be Tanya enters something into a search bar of your web app that you made, or there’s a hidden field and someone could have changed it, there’s something in the URL parameters. We got something from an API, we got something from the database. That’s all input to our system. And if we could validate that it’s what we’re expecting and that it’s okay to use before we make any decisions or do anything, we would avoid a lot of vulnerabilities.
Tanya Janca 00:04:58 Let me tell you. Same with connecting to things and integrating with other things. So we’re calling an API, are we sure this is the API, we meant to call, or maybe we are the API. It’s, is this front end allowed to call us? Is this a friendly front end? Is this another API calling us? Should it be calling us or is this actually a malicious actor? If we could not trust by default and always verify before we take our next step, so before we use that data or we open the connection or we allow them to touch our database or access our database, I feel like at least half of all vulnerabilities would just disappear overnight.
Brijesh Ammanath 00:05:40 Do any real world examples where assumed trust cost failures come to mind?
Tanya Janca 00:05:45 So as an example, just SQL injection. You get something from the user. So let’s say you are filling out the form, you seem nice, but I would still validate data from you. So you put something, let’s say we’re logging in somewhere, and so there’s the username and there’s the password. Let’s say because we’re not doing password less, we are not fancy. And you put into the username field a bunch of code instead of your actual username, right? So instead of putting whatever your username would be, you put in a space or a letter or something and then a space, and then a single quote. And you add on the classic injection code, which would be or one equals one space, dash, dash. So you put the two hyphens at the end and the SQL code, you’re like, I don’t need to see the rest of this.
[...]