Rey Bango, Senior Director of Developer and Security Relations at Veracode, discusses secure coding with host Priyanka Raghavan. They discuss the need for secure coding, barriers to adoption, how training can help teams improve at adopting secure coding practices; key principles of secure coding such as verifying for security early and regularly, looking at security issues as bugs, validating inputs, and being very aware of third-party components being used in open source development and regularly updating them. They considered the importance of logging and how verbose logging can be a source of attack, and then also discussed the cryptographic flaws in programming languages. Finally, they discussed future research in the area of usability and performance of security tooling.
Show Notes
Related Links
- SE-Radio 427 on Mobile application security
- SE- Radio 390 on Security in software Design
- OWASP top 10
- Security heat map
- Veracode documentation
- Martin fowler input validation
- Tanya Janca blog
- Hackme
Transcript
Transcript brought to you by IEEE Software
This transcript was automatically generated. To suggest improvements in the text, please contact [email protected].
SE Radio 00:00:00 This is software engineering radio, the podcast for professional developers on the [email protected] se radio is brought to you by the IQ, really computer society as your belief software magazine online at computer.org/software.
Priyanka Raghavan 00:00:17 Welcome to software engineering radio, and I’m your host Priyanka Raghavan in conversation with three bangle from better call today. We’re going to deep dive into secure coding and find out why it is important is a senior director of developer and security relations. And previously he focused on security practitioner relations at Microsoft and also lead developer relations for the Microsoft edge browser team. So we’re really excited to have you on the show. Welcome to the story.
Priyanka Raghavan 00:00:52 Is there anything else that you would like listeners to know about yourself before we jump into the
Rey Bango 00:00:56 I’m based out of south Florida. I been in the industry for well since 1989. So yeah, I’ve been around for quite a bit of time and seen plenty of stuff. I think one of my crowning achievements was being part of the jQuery project. And I know that, you know, right before the show, you and I were kind of chatting about that. And it was, it was a really fun time for me being a part of the jQuery project and seeing how things are growing and just seeing the evolution of developers and seeing how excited they were to be productive with the jQuery JavaScript library was, it was such a fun time. And this was before I got into security. So I think I was all I saw were unicorns and flowers and development. And now that I’m on the security side, I’m like, Ooh, what is all this stuff? Yeah. So I see all the barbarians at the gates trying to get in. So
Priyanka Raghavan 00:01:49 Yeah. Fair enough. So in software engineering data, we’ve done a few shows on cybersecurity, but we’ve really not dive deep into secure coding. So I think the first thing I’d like you to do for our listeners is to maybe define secure coding in your own words.
Rey Bango 00:02:04 Let me take a step back real quick. And one of the things that I do want to say is that as you’re going through your journey, and this is to your audience, just know that people are going to tell you, you need to be secure coders. You need to be secure coders. And I think that’s, that’s actually a reasonable request, but not everybody needs to be a security expert. That was something that I want everybody to understand. Security is hard. It’s as hard as software development. And if you remember what they always say, it takes, what is it, 10 years to become a master of anything you do. And so I’m sure that there are many people in your audience that have spent a lifetime honing their skills in software development. And it all sudden somebody saying, Hey, you need to be a security expert.
Rey Bango 00:02:43 No, no, no, no, no. That’s, that’s a whole different world. When you hear something about secure coding, what people are saying is to take the time to learn about patterns and practices, that help to ensure that the code that you put out, isn’t going to be vulnerable to a lot of the common attacks that are listed out there. We all talk about patterns and practices when we’re doing development patterns for everything from database access to object creation, dating myself a little bit. But I remember when I was working with the UML back when the room of days in Grady Booch and what were those, those were basically patterns. And so secure coding is, is basically patterns. Let’s say, if you, if you code things in a specific way, you consider a specific things, have you account for, I don’t know, things like proper parameterization and proper input validation, things like that.
Rey Bango 00:03:29 You lessen the threat landscape and the threat surface for a bad actor to compromise your system. As far as I know, I I’ve never met a developer who says, yeah, I want to write bad code. I want to, I want to write thugs. I don’t, I, you know, in fact, most of the developers I’ve ever met think they are the cat’s Meow. When it comes to writing code, they think they are the best coders in the world. I can tell you right now, I used to think that, and I look back at some of my code and like, I’m definitely not the cats hanging out coding, but you know, I certainly never wanted to write those bugs and I certainly didn’t want to have security issues. So that was, to me, that’s what secured coding is about. It’s just understanding what your code is doing and ensuring that as you take in data from whatever source, whether it’s an API, whether it’s a form on your, on a website, whether it’s a form on a desktop application or an input that’s coming in, let’s say on an ICS SCADA system, you know, an industrial control system that you’re taking the time to truly validate what that data means and what action is going to take.
Rey Bango 00:04:31 Now, there’s term called defensive programming and defensive programming. It’s more about building resilient systems, it’s accounting, for things that will cause a system to fail. I can see how pervasive that could be everything from banking systems like ATM’s or industrial control systems that have to ensure that people, that systems in oil refineries, or just in manufacturing, don’t fail and cause catastrophic failures or loss of human life. That to me is a little different than secure coding. It’s there’s some overlap for sure, but defensive programming can certainly be a part of that. It’s accounting for these things that you might not expect. And how do you fall back verbally? So your systems don’t fail and that you don’t have loss of business or worse loss of life.
Priyanka Raghavan 00:05:21 So we’re also of course, in now in the era of agile software development, right? So everybody wants to put out releases really quick. How do you sell the concept of secure coding to companies? And is there any metrics that you have that show that companies were able to avoid certain types of exploits by employing secure coding practices?
Rey Bango 00:05:44 Sure. Everybody wants to deploy faster. Who was it? Mark Zuckerberg said it build fast and break things or something like that, something along those lines. And so then that’s probably why Facebook groups had so quickly, they were constantly innovating and time to market as an important thing. And I understand that and you know, there’s a lot of pressure on developer teams to not only build really great features, supposed to build them fast. Now, what is the common sprint cycle? Every two weeks we have a sprint. That’s what I constantly hear. Every two weeks we have a sprint and there’s a tremendous amount of pressure for developers to build resilient code that is also feature rich and that’s hard. And so one of the terms you’ll hear quite a bit of shift left, and what it means is basically taking your thought process and incorporating security into the, into your development process, from the get-go and from, and considering it from every facet, whether you’re going in through the initial planning, planning stage of a project, or you’re in scoping or you’re in your CIC, D all security should be a part of that and should be a consideration it’s in terms of hard metrics.
Rey Bango 00:06:44 I wish I had a metric for you to share, but I will say that companies who embrace security and then also embrace to security tooling helped to identify flaws substantially quicker. Here’s the challenge. You have a flawless say, you do find a flaw. And a lot of developers may not understand what that flaw means. That’s the hard part. There’s a lot of tools out there. Open source. Some of them are proprietary that will help to kind of identify common issues, but developers aren’t security practitioners. And what ends up happening is that if you’re a developer and all of a sudden you’re being presented with a bug that says here’s a cross-site scripting issue, or here’s a cross-site request, forgery issue, or token security issue. In many cases, they’re not going to know what to do with them. And they’re not going to have enough context to actually know how to resolve that.
Rey Bango 00:07:34 And what we’ve, what we have identified is that in many cases, and I believe it’s a finger, something like 70% of developers who are presented with security issue, where they had no real context, it took them weeks and weeks, and weeks and weeks to fix it. And it was hard because they didn’t know. And so that gets pushed back to the side. But if you provide a developer and then hopefully a security champion or an AppSec manager with real context into what the security issue is, and what’s the implications of security issue, and hopefully some guidance on how to actually solve it. We’ve seen that the medium time to actually resolve those issues was dramatically decreased to something like, I think it was somewhere between two to five weeks and in QA cycles, that’s a pretty big deal. You know, that you want to have that increase in resolution and remediation as quickly as possible.
Rey Bango 00:08:24 Now, not all bugs are created equal. Some bugs are obviously high priority, and you want developers to have the context and take action on those high priority issues. You want them to know that if there is an API key, that’s been leaked inadvertently, which has happened. We want that to be fixed immediately. If there is a SQL injection that is leaking out customer data, well, PII is number one priority, no matter what I mean, anything that unfortunately releases customer information. It should be mission critical resolution. Like that is a price zero to me. And remember that GDPR has hefty fines for companies that are not taking remediation seriously. If you’re not managing PII seriously, if you’re exposing data because you’ve made a mistake, you know, mistakes happen. We know it. GDPR can be very unforgiving in that sense. And it’s important for companies to take those levels of compliance very seriously.
Rey Bango 00:09:20 So tools like what Vericode provides helps developers better understand what those bugs are and they are bugs by the way. I want to, I want to clarify one thing. Let me just say that the Vericode tooling will help to identify those bugs and offer the right context for development teams to take effect on them and remediate them and then make decision. That’s the other part of it. They need to be able to make decisions, because if you have a Prizer or PRI one, that might be an immediate remediation, if you have a PRI two or three bug, that might be something you’re going to push off, because you know that there’s not a direct impact. They, you followed the development stack and you seen that. Yes, it is. It could be a potential bug, but it’s not going to compromise the system and it’s not going to leak PII.
Rey Bango 00:10:04 So maybe that’s something that you tackle in a subsequent sprint, but going back to what I was saying about bugs, one of the things that I want to stress to your audience is that as developers, we always want to build a quality code. We always talk about that. And we always look at our code and when a form, you press on the posts, like a submit button, it doesn’t work. We know that’s a bug, right? And we’re like, yeah, we got to fix that. I think one of the things that we need to also start thinking about is that security issues are basically bugs. If you’re not doing proper input validation, if you’re not validating data types all the way down, all the way to accessing your database, that should be considered a bug. And the reason is because all those things could lead into other security issues or just resiliency issues.
Rey Bango 00:10:48 And so to me, security is related to software. If you look at every major hack that we’ve had in the last 10 years, for the most part, there’s always compromised a bit of software. I was talking to somebody just the other day. And I said, yeah, you know, one of the things I’ve come to realize is that every bug, every software issue, every security issue is a bug. It’s a software bug and you go, yeah, everything’s software everything’s software. And it is, if you hack an ATM you’re hacking software, if you hack a computer system that is running a website and you drop a web shell, that software, if you, if you hack an industrial control system, well, that’s running firmware, what’s firmware software. So we have to consider these things as part of our normal QA cycle. And we have to take it seriously. We have to learn how to prioritize those bugs.
Priyanka Raghavan 00:11:35 Would I be writing about a freezing? The, the barrier for adoption of secure coding is not thinking of security as a part of the sort of engineering design software design and the whole life cycle. Is that, would that be fair?
Rey Bango 00:11:50 I don’t know if I’d describe it that way and it could be, I could trust me. I could definitely see a lot of developers saying, oh, security. I don’t want it a lot. I want to do security. I just want to, I just want to sling code. Totally understand that. But I think security is secure. Coding can be a barrier because it’s something new. It’s not trivial in the sense that there’s new muscles that you have to develop and there’s patterns of practice you have developed. But I don’t know. I look at developers nowadays. It is the creativity behind them. The fact that they can pick up a framework like react or Django, or, you know, they can leverage hibernate and just go with it. And especially the young developers nowadays young developers are incredible. And so impressive. I think, I think from the moment birth has been given to me, they’re handed a coding book and says, here you go.
Rey Bango 00:12:38 And they’re like reading, you know, you know, they’re reading the coding book as they’re being fed. And I’m like, God, they’re so fast. They’re so fast to pick up things. And so the way I look at it is at that same level of speed and learning these new frameworks, because they’re so committed to becoming good developers. I think that there should be opportunities for them to learn secure coding. Here’s what I do see though. And this is, to me, the bigger issue about why secure coding is not being embraced. I think part of this is that when you go into the educational systems, whether you start at middle school or high school, and I’m going off to somebody, the United States thinking, or even the university level secure coding is not taught in these classes. I’ve spoken to professors that have told me, yeah, no, we have some classes here and there that try to incorporate some security aspects and topics to it.
Rey Bango 00:13:29 But in terms of a dedicated curriculum that says, this is how you build secure software. There’s nothing out there. And so we’re getting this new breed of software developers coming out, very talented, ready to go, and they just don’t have the fundamentals. So if you don’t even have the fundamentals, it’s really hard to expect them to build things that are going to be secured down the path they’re learning on the fly. And then to exacerbate the issue is that many employers don’t provide training for these developers. It’s very few and far between that. You are going to find software developers to say, yep. My employer sent me off to secure coding training, and I learned X, Y, and Z. Most of them don’t. And if they do, let’s say they go to a sands course and sands courses that are super expensive. They come back after a week and, you know, Priyanka, I’m sure you’ve taken a course.
Rey Bango 00:14:20 You’ve gone and you’ve taken a course. And then you come back after week and you had this workload in front of you and like, yeah, everything you just learned a week before, you’re not it’s out the door. I took a course. It was a sands , which is advanced exploitation. And I think it was extra advanced explication or something like that. And I remember learning about buffer overflows, so really advanced buffer overflow stuff. And I’m like, my head was, my brain was melting and I’m like, and I got back from that. And that was a six day course. And I didn’t use it anymore. And I can’t tell you that. I, I would know the things that they taught because it’s hard to digest so much information in such a short period of time and then reinforce it if you’re not using it day to day.
Rey Bango 00:15:08 So I would say that the bigger challenge to secure coding is the lack of education that they’re getting in the lack of reinforcement in the, in the workplace. I think the, you know, there’s, there has to be security champions that can help people better understand how to secure to the code. And there were a lot of companies that have actually embraced this. I’m glad they’re doing it. I think it’s, it’s a necessary function to have people are committed to learning security and then running with that. And then being there as mentors, serving as mentors to other folks. But we also need employers to say, all right, secure coding is a priority. I’m guessing that things like the solar wind supply chain attack and some of the other things that we’ve seen for the past, like the Equifax, uh, stress hack, all those things, hopefully are kind of, they’re opening the eyes of employers. I know I don’t want to know the colonial pipeline attack. And granted that was just, that’s just human error. You know, that’s somebody opened up a phishing attack, but ultimately the phishing attack managed to get into software and compromise stuff. I don’t want that. So that’s kind of my thoughts on that.
Priyanka Raghavan 00:16:10 Okay. Maybe you can switch some gears into a little bit on the tooling before we move into some of the flaws that I want to talk about. We’ve got this sort of static application security testing. So that’s one of the way that in our CI CD pipelines, for example, in my company, or we get a bunch of tools and we hook it up to the pipeline and it does all this checking of your code, but every time I introduced something like that, that are moans and groans, and then it gets pushed to the, let me do it as a nightly nightly build because it’s still is slowing down my pipeline. And actually to be honest, it does take awhile. So this is again, I find what this is, again, a barrier to adoption of maybe tooling and looks as a real daunting task. So do you have an advice on that? Do you see this kind of a complaint from other people that you deal with them? What’s your advice on? As soon as I check in the code, there’s going to be no tests running on it. I mean, this kind of fast or whatever tooling is not going to happen, then it’s not really a giant rape. So what’s your advice from,
Rey Bango 00:17:12 I do understand what you’re saying. And I think when you add more things into a CICB pipeline, you’re always going to have some level of like new latency added to it. It’s just, I think it’s part of a normal part of a development workflow. And I understand developers getting frustrated by anything that adds even 10 minutes to their workflow. What we’re seeing is that for the most part, the tool chains that are created are pretty, they’re actually pretty fast. If you consider that, obviously you’re, you’re trying to S you may be trying to scan a massive code base. And unfortunately it has to be done. There’s ways of compartmentalizing that whether it’s through microservices or compose, you know, creating, uh, components that are more easily scanned, um, in terms of like re like steps that I can tell you, it’s, it’s always going to be on a case by case basis.
Rey Bango 00:18:02 There are times when we’ve seen really large applications that scan super quickly, and it’s, it’s based on the way that the developer has built it out with, again, whether they’re leveraging microservices or they’re, you know, they’ve just built a really well-designed component-based architecture. And those things tend to make things flow easy, but again, very large monolithic applications. Sometimes it’s going to take a little bit longer because it is what it is. It’s a massive code base that has to be scanned through. And especially if you’re dealing with legacy, legacy code bases, that could be a challenge. But overall, I think the tools that we’ve seen have been pretty good, they’ve been pretty good at parsing through code bases. And it’s, I wish I had a silver bullet that I could share with your, your audience and say, this is what you need to do, but there is no real silver bullet. Every single application is unique. Every single application is going to have its challenges.
Priyanka Raghavan 00:18:59 Fair enough. So maybe now we can move into the one piece of white paper that I found on Vericode, which actually I based a lot of my questions on that was the heat map that was put out. And I think it’s fascinating reading. I’m actually going to put it in the show notes. One thing I noticed you’ve already, actually, when I asked you, I introduce more about yourself, you said that you’ve had a long history of software development. So I want to throw some few languages at you. But broadly from that paper, I noticed that obviously these frontend code had certain types of flaws. And then if you looked at languages like C plus plus, they had like Buffalo floors. And if you looked at dotnet, there was, you know, uh, information leakage, Java had certain other types of flaws. So that made me think, is there some sort of architecture which results in certain types of security flaws?
Rey Bango 00:19:50 That’s a good question. And I think there, there clearly are. I think if, uh, if you look at C plus plus, and I’m not a SQL splits expert, I’d done some tinkering in it. And I know that if I tried to write something now, oh yeah, that’s a buffer overflow just waiting to happen. Absolutely. And part of that is because if you think about it, C the C language and C plus plus languages are meant to offer you basically the ultimate level of flexibility in the way you build something you’re responsible for everything. And while C plus plus helps to abstract some of the complexities through object oriented programming. Ultimately you’re still responsible for memory management, to an extent, and to a large extent. And so that’s where I think developers will make some human errors, normal stuff, especially, especially as you’re starting out, it’s really easy.
Rey Bango 00:20:36 I’ve spoken to , it’s really easy to make mistakes. When it comes to memory management, it’s really easy to open yourself up and expose yourself. If you don’t know how to manage that properly, which us to some other languages. One of the reasons we see a lot less issues with like managed languages like JavaScript is because, well, JavaScript is for the most part sandbox sandbox within the context of the browser. And it’s not to say that it can’t be compromised. We’ve seen plenty of them in the edge browser, the Chrome browser Firefox all these browsers. They do their best to sandbox it, but ultimately, you know, a language takes input. And that’s what, that’s what it’s meant to be. It’s meant to allow you to create an application that it takes input. And once it takes input, things can happen. There’s a lot of capabilities out there for attackers.
Rey Bango 00:21:21 I’ve taken a lot of offensive security training, and I see the capabilities that are out there from a fuzzing perspective. And when you throw a large amount of data at any of these languages, you’re bound to find something. And whether it’s just a simple crash, which I crash is bad, you know, but thankfully it’s that releasing information to actually a full-scale compromise. The languages all have issues. Uh, Matthew Hickey, who was the first instructor I ever had said, great, all computers are broken. It’s true. Is his act. His famous acronym is a cab AC AB our computers are broken. And I never thought about that until I took his course. And sure enough, I agree with him on that. All they’re all broken, and then you can find security issues. Now, in terms of other managed languages, whether y.net is prone to information leakage, I wish I had a clear answer for you on that.
Rey Bango 00:22:12 I don’t have that one. It’s easy. It’s so much easier to tell you about C plus plus obviously, because that’s, that’s a clear one to me, you know, that’s, that’s, that makes sense. But it’s really hard to tell you why developers are more prone to information leakage, and it could be everything from the breadth of the dotnet ecosystem, which has a lot of moving parts to the way the applications are scaffolded. Now, remember that, you know, when you build it on application, yeah. You can build a console based application. You have wind forms, you have desktop based applications. You have what I think they call it razor or blazer. Now all these different facets of the ecosystem can expose some aspect of your, of your system. And then the other part of it is that a lot of developers just simply, they make mistakes. When we talk about infrastructure’s code Yammel files, things like that, what do we do in those?
Rey Bango 00:23:05 We’re basically defining commands that allow us to scaffold up something. And so when you’re creating a Yammel file, you’re passing commands and sometimes API keys that say, I want to do this. And here’s access to a critical system where you’re going to find this bit of information. And so if you’re using something, let’s say, like get hub for your CICB pipeline or Jenkins. Well, typically you’ll be able to define variables in those systems that basically obscure that. But the fact that we still find API keys in GitHub, repos left, and right, tells me that in many cases, developers are forgetting that things like API keys, passwords, yes. Passwords should not be in your code base. So I can see that level of information leak is being put out now, having come from Microsoft and speaking to the dotnet team extensively, I can tell you that they have a dedicated team that focuses on security.
Rey Bango 00:23:57 They’re just for.net. And so I think overall, they do a fairly good job of protecting the end users, especially because there’s, there’s such a commitment to corporate and enterprise customers. And one of the things I always hear is that source is more secure because they have more eyeballs on it. And I would challenge that one. I’ve been part of an open source project. I don’t think that’s necessarily the case. I think open source is faster to resolve security issues because in many cases they have so many people contributing to the code bases that they’re willing to jump in very quickly and take care of that. But in terms of the many eyeballs stuff, I don’t think that’s necessarily a case. I haven’t seen it because there’s a lot of security flaws out there in open source code. One of the things that we found Priyanka is that in many cases, developers what say, bring in a library and open-source library into the project.
Rey Bango 00:24:48 Most of the time, it doesn’t get updated. Think about that. Think about the implication. You’re a software developer you bring in, I don’t know, let’s use jQuery as an sample and you bring in January 1.0, and it’s partly, it’s a critical part of your system and you just let it run and you never update it. Well, I know for fact that there have it’s as 1.0, there had been a slew of security issues and it’s the same with react. And it’s the same with Django. And it’s the same with Ruby on rails and any framework. And then, you know, you, you think about the packages that are being incorporated because of course, all these frameworks have package managers now and they have, and the languages themselves, that package managers, you have Ruby gems, you have PI NPM, all these things are, if you think about it, what is it?
Rey Bango 00:25:37 Third party code. One of the fallacies that I’ve seen is that many developers perceive code that’s residing on package managers as safe code. And it’s not, it is third-party code. And if you haven’t taken the time to vet third-party code to understand what that code does. And then not only that understand the dependency chain of what that code is incorporating. There’s no way that you’re going to know whether your code base is safe. This is where things like software composition analysis comes in, where you’re able to leverage tools that can, at the very least go down the dependency chain and figure out is this a vulnerable package? Should this be updated? And I think that’s, again, it goes into the whole QA cycle where these bugs need to be identified and then needs to be bubbled up. And so it’s not only SAS it’s nowadays because we’re incorporating so many other components into our applications, third party components. We have to be cognizant of what we’re ingesting. And we have to be cognizant of how we update that the same way we patch our operating systems. We need to be stay on top of the software that we’re building, because once that goes into production, if we don’t stay on top of it, well, sooner or later, somebody’s going to find out that it’s not patched. And that’s where the security issues come in.
Priyanka Raghavan 00:26:58 I, that was one of the questions I was going to ask you. So it could be spoke about it right away, I think. Yeah. What do you see? We want to develop faster. So just pick up something and, you know, let me just try and use it and no, not really much thought that goes into it.
Rey Bango 00:27:11 And it’s a scary proposition. I know I’m just on it, but it’s, it’s, I’m guilty of this, by the way, I’m guilty of doing NPM install. I was very much into JavaScript and very much into node. And NPM install was my friend. And I didn’t think much about it until Adam Baldwin kind of was the person who really put me, you really put a spotlight on the problem. And so Adam Baldwin, he started the node security project, which eventually was acquired by NPM. And he ended up being, if I remember the chief security officer or some very senior role at NPM relating to node security, and he always talked about the coming apocalypse for node package manager. And it’s true because, and he demonstrated how a simple package could lead to compromise in a system. And if you think about it, what was it? There was a, a module called I think it was pad left and NPM where the author got upset for some reason, decided to yank that package off of MPM entirely.
Rey Bango 00:28:13 Basically, I think it crashed something like 30% of websites. So that’s the show you how developers aren’t taking into consideration the implications of ingesting third party code. It actually goes back into the whole defensive programming thing. If your application went down because you were directly incorporating code from a package manager, instead of bringing it down, analyzing a code and trying to figure out how to incorporate into your, your build process, that that’s not defensive programming, you’ve just caused your system to go down because you relied on a third party that could easily go away in a second. NPM is not a hosting provider. They’re not a CDN. They’re there to allow people to contribute packages to an ecosystem. And if that package goes away and you’re relying on it and you’re taking a direct link to it, your system is going to fail. Node source tried to do a good thing.
Rey Bango 00:29:07 And I, and I know that they continue to do it and trying to create vetted packages. That was actually very smart. I think it was the right thing to do. You look at the most common packages, do us an audit of it, just to understand what the code is doing, and then take a snapshot of it so that their customers can feel confident that when they’re ingesting this code via probably a private package manager, that they can feel confident that Dakota’s not going to compromise the system and that the Cody will be there when they need it.
Priyanka Raghavan 00:29:34 I think, yeah. Having a private package manager, probably a good thing to do for all of us. So I think that’s that’s point number one. And I also think the other thing that you said was also, it’s not only coding because you’ve talked about your Yammer files and data form, or there was, so that also infrastructure is code is also secure coding. So make sure that your tools also run through that. So those are two interesting points
Rey Bango 00:29:57 And I haven’t dug into infrastructure as code, especially from a security perspective. I know this is a whole, all that is definitely evolving. There’s much more interest in how do you secure that? And so that’s kind of the, some of the new things that I have to learn about, but it makes total sense. You’re leveraging Terraform to deploy a whole environment. And if that’s not secured in the right way, that’s easily accessible to a third party. Imagine the implications of that. I understand why so many people are now saying we need to protect our infrastructure as code. And I’m glad that they’re seeing it as code. It’s actually really interesting because for the longest time it administrators, they never thought about touching code. They were like a code that’s where the developers, it’s kind of like how developers always thought security is for the it administrators.
Rey Bango 00:30:42 Now it’s going full circle. Everybody’s thinking about each other’s jobs. Basically. I think it’s important that we consider the whole entire production life cycle of an application and where the security vulnerabilities could be. I think now more in terms of security, obviously, because that’s where my head is at. But from a development perspective, you know, continue to think very closely about how your applications are being deployed. That’s going to be your number one priority, but also start thinking about what are the touch points that a third party could have. That could cause a problem, not only from a security perspective, but from a resiliency perspective in your code base, if you PR, if you publish something, is it going to work the way you expect it? Not only from a security perspective, but from a stability and resiliency perspective, if not, and that’s where I challenge you to kind of go through there and reevaluate, why is it going to fit?
SE Radio 00:31:36 I see radio listeners. We want to hear from you, please visit sc-radio.net/survey to share a little information about your professional interests and listening habits. It takes less than two minutes to help us continue to make se radio even better. Your responses to the survey are completely confidential. That’s S e-radio.net/survey. Thanks for your support of the show. We look forward to hearing from you soon.
Priyanka Raghavan 00:32:01 One of the principles I saw on the Vericode website was verified for security early and often. So I guess this kind of fits into that, right? Because you’re thinking about the whole life cycle, but pretty early on in the game,
Rey Bango 00:32:15 You know, a lot of people talk, they call that shift left, think about it early on. And there’s so many great articles written about shift left. I mean, Tanya Janka who’s. She was actually a former colleague of mine at Microsoft is one of the foremost experts. I would urge your audience to look at Tanya and look up her readings. She has a great book on the application security, which she dives into that quite a bit and building secure applications. She’s a great resource. And, but yeah, it’s all shift left. What they’re saying is you should be thinking about how security plays a role within your whole entire life cycle. Remember that when we create an application, we first have to go through a scoping process. We have to understand what the business needs are. We have to understand who the stakeholders are. Even before we get to like writing a single line of code or doing a database model or figuring out what type of database for new use, we have to scope it out.
Rey Bango 00:33:04 And I think understanding what your threat model is, understanding who your audience is, what are the things that you’re going to be ingesting? All those things come into play to make helping you make really good decisions. Whether you need to sanitize inputs, how are you going to sanitize inputs? How are you going to protect your database? How are you going to deploy your code in a secure way? What systems with 30 parts are third-party systems, do you need to integrate with, and how are you going to secure your communication with these third-party systems? If you’re putting out an API, how are you going to secure that API so that you don’t have PII exposed? Those are things that, from a shift-left perspective, it’s just basically saying, think about it early so that you’re not caught off guard later on. You want to go through the whole cycle and eat, and remember, this is an iterative approach.
Rey Bango 00:33:52 This is not just saying, alright, I’m going to shift left, and then I’m going to go, right? And then I’m going to forget about it. No, you also have to keep going, right. And you have to think about, well, what’s my security posture. Once my applications out in production, how do I continue to evaluate what that means? What does my application security look like once it’s out in production? How do I test that? Do I need a third party to test it? Is my code producing the results that I expect. Can I have somebody fuzz that and blow it up in some fashion? Those are the things that are more proactive testing that you should be doing as an organization anyways. And that could be outside of the scope of the development process, but I’m a big fan of pen testers, web application, pen testers, do a great job of being very creative.
Rey Bango 00:34:35 If anybody in your audience ever wants to see how creative they can be, just go to bug crowd and or hacker one and read the reports and look at the things that they find. You know, we, a lot of people talk about cross-site scripting because it’s still one of the most pervasive things that you’ll find it, especially in web applications. And they always say, yet you have to sanitize inputs, you have to standardize inputs. And I’m like, okay. Yeah, you can try to sanitize. And that’s really hard because you’re not going to catch everything. And then you’re not taking into account different types of encoding, different types of language specifications, things like that. I’ve seen some of these bug hunters do the most wild code injections by contorting characters. They’ll put a slash slash and then an asterix and then another slash followed by this backslash.
Rey Bango 00:35:23 And all sudden they somehow managed to have found across site scripting attack. And it’s that ingenuity. That part of me is impressed. Be grudgingly impressed, you know, cause you, of course, you know, I don’t want anybody hacking stuff, uh, that they’ve known, but seeing them, you have to be impressed by the fact that they’re so creative and these bug hunters are being that creative. To me, it makes sense that threat actors are going to be that creative. So how do you defend for stuff like that? Remember when I mentioned that you have to make sure that you have to validate the inputs that are coming in. And part of that is validating things like data types, all the way through your, your chain, it’s leveraging ORMs and worms are available. And what hibernate, I think hibernate has one Rubion rail has, what do they call it?
Rey Bango 00:36:08 God rails, validator. I think it’s called. And a lot of these ORMs are great at validating input and making sure that the data types that you’re expecting are actually being interpreted correctly. It’s not to say this is not a catchall. I don’t want that to people to expect that the validators that are included in some of these framers are gonna be catchalls, but they definitely help you get part of the way. I actually think whitelisting helps quite a bit creating a white list of acceptable inputs can help quite a bit as well. And there was some code that I recently saw. It was there, it was vulnerable code, but it was still, I understood what they were doing. And there was PHP code and they had white listed, actual extensions for a specific type of files they were doing. They were actually validating two things.
Rey Bango 00:36:53 It was supposed to be validating for image file both from an extension. So these were the only four extensions you can use. I think it was like JPEG, J P E G P and G and GIF. And then also validating that the file had a what’s the best way to describe it, to kind of like fingerprinting the file for image attributes. And it’s actually pretty unique. I had, I had never seen that and I was like, that’s pretty, but what they’re doing is they’re basically white listing. Now in this case, it was one little SPLA that allowed somebody to bypass that by incorporating PHP right in front of the JPEG. I think it was a pending it, but that’s, again, it shows the ingenuity there. If somebody said, okay, I can get around this by putting a PHP at the end of it, because the array that was parsing, it was only parsing.
Rey Bango 00:37:39 It was parsing out the file name and the extension, and then taking the base file name and then passing that through. Well, when you look at it, it was, you would upload something like food dot, JPEG dot DHP, what would only parse food dot JPEG and in the PHP file is still there. So it upload it and then you can get a webshop. So it’s clever things like that that you have to account for. But if you can white list and you can kind of do those checks all the down all the way down through the stack, it helps tremendously. And don’t depend on front end validation. I mean, I think front end validation is kind of like, I don’t know, I just bought, I think you can do it as a cursory check. Like if you’re saying let’s make sure phone numbers are formatted in the right thing when they’re inputting it.
Rey Bango 00:38:26 But I think once it gets down to the service side, you should validate again to make sure it is actually a phone number in the way you’re expecting it. You want to make sure that somebody is not saying drop table. That’d be pretty bad. You know, those are the things that, and then you should also be encoding your stuff. You know, we use templating languages so much in our development efforts. The stuff that you save could have a dramatic effect. Once it gets rendered by his templating languages. Again, the tiptoeing language are super powerful and they’ll take inputs and they are going to perform the way that they expect it before. So if you say something like, all right, I want to go ahead and I don’t know, render a Dom element. Well, that Dom element just happens to be a cross site scripting attack.
Rey Bango 00:39:09 Well, guess what? Now you have a cross-site scripting attack. That’s going to go ahead and grab it, grab the cookies from your session and maybe send it off to a remote server that you’d never know about. So those are some of the things that you just have to take into consideration. There’s a person, his name is Martin Fowler, and I’m happy to give you the link Martin. Fowler’s fantastic. He wrote such a great piece on so many different ways of checking for your input validations. I think it’s like, it’s almost like the Bible it’s input validation, you know, so,
Priyanka Raghavan 00:39:39 Okay. So check that a big fan of his writing. I think he was on the shore. So what before?
Rey Bango 00:39:45 Yeah. Martin followers, it’s still stuff that I read and I go to, and of course the Vericode knowledge ways is great. I would definitely recommend that everybody who wants to get deeper into AppSec go to the Vericode knowledge base on our, on the vericode.com site and just go through it. There’s so much stuff that Vericode has acquired over the last 15 years. The way I look at it is if you’re a developer and you want to get into it, capitalize on the folks that have been there and done it for a long time, it’s really hard to learn something new. And if you look at the internet, the internet doesn’t make it easy nowadays, it makes it really challenging because everything’s piecemeal. You have to go from one site to the next, to the next, the next. So if there is a site like the application, like the Vericode application, security knowledge base capitalize it, Chris myself has been doing this for a very short time. He’s the one who founded the company and you know, between him and Chris Ang and Darren Meyer and all these people who are just amazing security professionals, which unlike I learned from them every single day, capitalize on the material. That’s there. I’m still learning every day. And I go to that because there’s stuff that I’m not going to be an expert in. And I know it. I have to know my limitations.
Priyanka Raghavan 00:40:52 We’ve covered a fair bit on the input validation. A few days back, I was sitting in a pen testing session on one of the apps that we working on and the vendors actually struggled to find this kind of, we had like basic input validation was pretty good, but then he came up with the flaw. He found a flaw by actually reading our exception logs. And then he found some, one little bit of B. So I was wondering if you could touch a little bit on, on that aspect, how much is too much to give away in the exception logging? Do you have some advice on that? Because it looks like that’s again, we need that for diagnostic, but then it’s also like, it’s a double-edged sword, right? Like you need it for diagnostic, but then
Rey Bango 00:41:35 Yeah, I’m a believer that your diagnostic codes, your framework and system diagnostic codes, shouldn’t be revealed. That’s just my personal opinion. Some people may argue with me on that, but you know, I did a lot of ColdFusion development way back when that would be, I’m showing, I’m showing my age now cold fusion and power bills are and all these things. So, and I remember cold fusion used to produce such verbose output to the point where you would know directory structures and database names and sequel queries and all these things. And this was back way before like security was such a thing right now, you know, like compared to what it’s right now. And eventually, like it was realized in the community that all that stuff could be used by bad people. I don’t believe we should be putting out anything. That’s going to describe what our platform is capable of doing.
Rey Bango 00:42:29 That’s just my take on it. I think it’s important that if you have an error, you handle it gracefully. And that exception log is clearly in the backend. I was thinking about NewsBlur recently and used blurs of an RSS reader and how they unfortunately were compromised. Recently. They had inadvertently left them. I think it was a Mongo DB instance opened some, but some hacker went in there and tried to ransomware. And, but you know, Samuel Clay, he’s the creator. He’s, he’s great. He had a backup and he’s like, yeah, you’re not getting my stuff. And I’m like, it’d be good money, but either way it was cool. I was glad that he was able to do it, but all that logging was on the backend. And by him having ample logging in the backend, he was able to trace down what the IP was that actually compromise, or I don’t want to say compromise.
Rey Bango 00:43:15 It was a script kitty who got in there and had an open database. All right. That logging all happened on the back end. I don’t know. It’s a hard question to answer properly because I know that for some systems, maybe it is mission critical to have this type of output. And I think if you have an internal system that, you know, you have complete control over and it’s not going to be out in the public, maybe it’s not a big issue. I personally don’t think so. I would prefer as a developer to be able to get any type of issues sent to me, either through a JIRA ticket or some kind of logging mechanism that I can go to and validate myself. I don’t think you should be splitting that to the end user. There’s no reason why an end users should know what your file structure is or what database are you using or things like that. It’s just, that’s just my take on it.
Priyanka Raghavan 00:44:03 Don’t do anything stupid like that on your front end or whatever. What do you make it a valid message I guess, and not give away too much enforced.
Rey Bango 00:44:13 Yeah. And also be careful Deepa code. That’s the other part of it? I mean, one of the things I’ve seen so much is developers will put Deepa code in. They forget to take it out now, thankfully, a lot of the package builders nowadays, things like Webpack and stuff like that. Uh, if I remember it’s been a while since I’ve had to do this will actually strip out some of that Depot code for you, which is great. So as you’re going through your build process, they knows, alright, these are, these are tokens that I need to strip out. And that’s great. So I would say capitalize on that. If your, if your framework allows you to strip out Deepa code, please do that. Please do it during your build process. Don’t leave it in there so that everybody can see the things that you’re actually logging out to console. Because look, I can do view source. I can press control shift, I, and immediately see what people are doing. It’s like, Zencaster and see whether they’re doing
Priyanka Raghavan 00:45:01 One of the few final questions I have is I saw a little bit on this cryptographic flaws on the Vericode heat map. I personally didn’t quite understand a bit about that. So maybe you could give some examples of what are these types of floors that people should watch out for them.
Rey Bango 00:45:18 Yep. And mind you, I am not a cryptography expert. That is like a rocket science to me. People who understand cryptography deeply. I admire them because that’s a lot of math. That’s what it boils down to. And ultimately the math can be challenging. And so I think what you see a lot is developers don’t realize that there’s a lot of stuff, 30 built for them and they don’t have to reinvent the wheel. There’s so many, there’s so many projects that want to reinvent cryptography. And there’s so many libraries like B crypt that’s been around forever. That’s works. And there’s no reason for you not to use it. And then to me, one of the worst is seeing projects to store sensitive data un-encrypted and remember data should be stored encrypted, whether it’s at rest or in transit. So not just because you have your little lock icon in the address bar because you’re using TLS.
Rey Bango 00:46:14 Does it mean that that’s the only place that the data should be encrypted? It’s great that you’re providing your end user, the ability to have a secure session. You want that data to be transmitted securely and encrypted. But once you receive that data, you should have mechanisms in place that will secure that data all the way to the database at rest. You need to treat the PII like it is the most sensitive bit of information ever. And GDPR basically dictates that. And so you want to make sure that you’re using industry best practices and standards for encrypting your data. You know, basically salted hashes, things like that, so that somebody, God forbid, if your system is compromised and your database is compromised passwords, aren’t easily cracked. And there’s a lot of capabilities. I mean, hash cat is great for that, but there’s so many services nowadays that can easily go through rainbow tables for people who haven’t hashed.
Rey Bango 00:47:10 Even if you do a simple half and you can do, I don’t know if you do an MD five hash on your database, you’re asking for trouble because MDA and D five is notoriously weak. You know, all you need is a set of rainbow tables and they’re gonna, they’re gonna run it through hash cat or some kind of password cracking server that they have and know they’re going to find what it is. And so that’s why there’s there’s procedures in places for this. This is stuff that is known. And if you’re not taking those steps to educate yourself on best practices for storing data at rest using best, you know, best practices, cryptographic software capabilities, you’re going to put yourself in a bad situation sooner or later. So I think that’s where we’re getting. When we talk about cryptographic, it’s mainly that it’s leveraging, leveraging the technologies that have already been proven.
Rey Bango 00:47:54 Don’t reinvent the wheel. You may be really good at math. Maybe you scored an a in calculus while you were in, you know, in your class. That doesn’t mean that you’re going to build the next great cryptographic algorithm. And if you decide you to do it, that’s great. Do it, please, especially with quantum computing coming out and everybody’s freaked out about it. If you want to do it more power to you, but make sure that you also validate it with the industry before you say, this is a great next cryptographic algorithm that we’re all gonna use because yeah, somebody’s gonna use it. And that can be problem
Priyanka Raghavan 00:48:24 If I would just to summarize. So we’ve talked about a few things that developers should keep in mind. One was verified for security early. Like, so keep thinking about it, do it often. Then we talked about input validation, how important it is also about logging. Don’t like do stupid stuff and, you know, put important things onto to the end user. Then we also talked about, you know, cryptographic flaws, how to reduce that. And also a little bit also in terms of about a third party, we spent quite a lot on a third party. Libraries are using, please check that. Is there anything else, one final thing that you want to add that we should keep in mind when we are doing secure coding.
Rey Bango 00:49:00 I just want to reinforce that this is secure. Coding is a journey. This is not something you’re going to learn overnight. And I can’t stress enough that it’s important for employers to give their developers an opportunity to learn secure coding principles while they’re working, give them the time to do it. And because a lot of times they’re not going to get that training in school and they’re going to come onto a job and they’re going to be expected to know it. And I don’t think it’s fair for somebody to require their, their employees to learn things on their own time. I think if you want to learn secure coding principles on your own time, because you just love it and you want to do it more power to you. It’s like, that’s how sometimes that’s how we learn things, because we just love it. We’re passionate about it, but it shouldn’t be a requirement. I would love to see employers taking the opportunity to make that investment because ultimately it’s gonna save them a lot of pain down the road. It’s going to make sure that their systems are more resilient to threats. And also just system ability. Take the time to invest in your, in your people because they’re putting a lot of effort into building great systems. I know they don’t want to build bugs. I don’t think you want them to build security issues. So help them solve that problem.
Priyanka Raghavan 00:50:10 Okay. That probably answers a back of the cultural thing as well. Right? Because then the companies invest in you. So then you become better. And then that changes the whole thing. Putting security in the, as one of the tenants of good software development, since you work for a tooling like Vericode, I had to ask you this question. So one of the things that I always struggled with is people always, when you’re doing these architectural workshops, you say, okay, they say, is it security or performance? Is it security or usability? Then they ask you to trade off. Right? And it’s a hard position in terms of research or what tooling manufacturers are doing for these kinds of questions to be answered. Can you give us a peek into it? Like, what is the next big thing from the secure coding world of research, or, you know, from two manufacturers to like answer these kinds of questions and say, you can add these many layers of checks and your different parts of the code, but you can still have like super fast code and super usable code. I don’t know if that’s a tough question, but it might be very exploratory, but yeah, that’s what I wanted to find out from you. If that’s anything on the research front that you could give us,
Rey Bango 00:51:18 Uh, I wish Chris Ang was here because they’re the ones that do a lot of the research and, you know, they, they could share that with you. From my perspective. I think the big thing that development teams have to understand is that again, it’s a journey. It’s a journey when you’re implementing tooling. And so when you first go through a process of incorporating a SAS tool or something like that, you’re going to have some pain points. It’s like anything you have to understand that you’re going to have to figure out how do you prioritize results? How do you incorporate this into your pipeline? How does this become a normal part of your workflow? And at sometimes when you get the results, you’re going to be overwhelmed and be like, oh my God, there’s so many bugs in here. But as time goes by, it becomes easier because you’re solving the bugs and those bugs won’t be there the next time.
Rey Bango 00:52:00 And not only that, you’re learning from those bugs and hopefully that’s helping you build better code. You’re not replicating the same mistakes. So I would say that, you know, it’s, well, it’s not research specific. It’s more of like best practices and understanding that, yeah, there’s going to be some pain when you incorporate any type of new system into your process and security’s no different, you’re going to find a whole new set of bugs that you’re going to have to learn about and figure out how to solve and work through and prioritize. That’s just part of the process. But once you have that, and once it becomes a normal part of the day-to-day, your code will just flow, perform. It’s funny because when you’re here, should it be security or performance? I don’t think you have to compromise on either. I think initially you’re going to feel some pain and that makes sense, like everything and you, your process might slow down a little bit as you’re building your process out. But once you get into the normal day-to-day actions of seeing the code being displayed as a bug and saying, I’m going to go and solve it as a JIRA ticket, it’s just part of my day to day. It’s just going to be a normal, normal thing. It’s not going to affect you at all. I don’t think it’s a trade-off.
Priyanka Raghavan 00:53:12 Okay. I think that’s something I’ve learned today. So that’s great. So one last question I have to ask you, where can listeners reach you? Would it be Twitter or LinkedIn? Could you like give us your handle so that people can bug you for more questions?
Rey Bango 00:53:29 Not a problem. So the best place to reach me at is on Twitter. My Twitter handle is spelled R E Y B as in boy, a N G O. So Ray Vango, I’m very active. And if you go there, you’ll see that I have quite a bit of tweets. I love Twitter. Twitter is such a great way of communicating globally with a big variety of folks and just know that I don’t always treat just about security stuff. I tweet about everything. I don’t know. I’m just pretty open in that sense. I would say LinkedIn is less. I tend to be more on Twitter. And then of course, you know, go to vericode.com where we’re going to have more content being produced. Now the team of Eric has asked me to kind of lead the charge on some of the new content we’re rebuilding. So I’ll be producing more blog posts around the application security. So definitely go to vericode.com and you’ll still, hopefully you’ll see my name on the Vericode blog soon enough.
Priyanka Raghavan 00:54:17 I do have a link to that on the show notes, but yeah, I learned that as well. So thank you for coming on the show.
Rey Bango 00:54:25 Thank you for having me. This has been wonderful. I appreciate it. This
Priyanka Raghavan 00:54:28 Is
SE Radio 00:54:32 I see radio listeners. We want to hear from you please visit sc-radio.net/survey to share a little information about your professional interests and listening habits. It takes less than two minutes to help us continue to make se radio even better. Your responses to the survey are completely confidential. That’s S e-radio.net/survey. Thanks for your support of the show. We look forward to hearing from you soon. Thanks for listening to se radio an educational program brought to you by Tripoli software magazine for more about the podcast, including other episodes, visit our [email protected]. To provide feedback. You can comment on each episode on the website or reach us on LinkedIn, Facebook, Twitter, or through our slack [email protected]. You can also email [email protected], this and all other episodes of se radio is licensed under creative commons license 2.5. Thanks for listening.
[End of Audio]
SE Radio theme: “Broken Reality” by Kevin MacLeod (incompetech.com — Licensed under Creative Commons: By Attribution 3.0)
