191 Is Open Source More Secure Than Closed Source?

Are open-source packages more secure than closed-source versions? Should I avoid closed-source dependencies because they are less secure? Why would I use a closed-source dependency in my project? These are the questions we will answer in today's episode of Dev Questions. 

Website: https://www.DevForge.com/ 
Ask Your Question: https://suggestions.iamtimcorey.com/
Sign Up to Get More Great Developer Content in Your Inbox: https://signup.iamtimcorey.com/

Transcript

Copy Transcript Copied

SPEAKER_00 0:00

Welcome to the Dev Questions Podcast with Tim Corey. Join us each episode as we tackle the questions you are asking about a career in software development, understanding the industry, and new technology. If you're just starting out or you want to grow stronger as a developer, this is the place to get your questions answered. Now, here's your host, expert developer and online educator, Tim Corey.

SPEAKER_02 0:26

Is open source more secure than closed source? I bet you know my answer. Let's talk about it in today's episode of Dev Questions. Now, this comes from the suggestion site. If you have a suggestion, go to suggestions.imtimcorey.com and leave your suggestion there. So is open source more secure than closed source? Well, it depends. So let's talk about the golden scenario of open source, okay? The golden dream of what it could be. So because the code is open, people review it. And because people review it, bugs are found. And because bugs are found, the bugs get fixed. And because the bugs get fixed, the code is more secure. That's kind of like the dream of open source, and it can work that way. In some cases, it does. So that sounds really secure and really awesome. And there's a lot of cases where that has made for better software. But here's the reality. The reality is just because code is open doesn't mean people have reviewed it. Just because people have reviewed it doesn't mean they found the bugs. And just because the bugs have been found doesn't mean they're fixed. So there's some flaws in that logic, right? And the people most incentivized to find bugs aren't the ones that are scanning it for good purposes. The people most incentivized to find bugs are the people who want to exploit them. So your code may be scanned, bugs may be found, and exploits identified, but are they identified by people who are looking to make your code better? Or are they identified by people who are looking to take advantage of those exploits? So let's look at closed source software. So for closed source software, the fear is that bugs are there, but no one's found them. And as a result, the software is less secure. And the people incentivized to find bugs are the people who want to exploit them. So that can be true. It can be true that if you have, if you write software, let's just pretend you're the one creating the software. If you write software, you might have a small team. No one has a team that's overly large. It doesn't feel like it. I don't see any developers out there complaining that they have too many developers and not enough work. That just doesn't seem to be the case. Instead, what happens is you have short time frames, you have limited budgets, you have limited time to do things, and you're crunching to get as much as possible done in as short a time as possible because you just don't have the resources to do everything you want to do. So with that, things get missed. And yeah, that can happen. That easily can happen. And what can happen then is there's vulnerabilities that you didn't notice because your team is only however big your team is as compared to the rest of the world. So there's a lot less eyes on that code. But it's also true that it's harder to find bugs to exploit in a black box. So there is kind of that balance too. There is something called obfuscation where you kind of hide something because it's obscure. So there's some benefit there. But there's kind of a a weighted reality here, right? So the reality is just because the code is closed sourced doesn't mean people haven't reviewed it, too. It may have been reviewed by a third-party company, it may have been reviewed by really good developers. And just because it's open doesn't mean that people have reviewed it. So software, regardless of open or closed source, is vulnerable. That's something you have to remember is that it does not matter if it's open source or closed source, it is potentially vulnerable to, well, they're all vulnerable. They're all vulnerable to exploits because we just don't know all the exploits and we don't know every possibility, and there's always going to be bugs they find in software. So everything is vulnerable. And that includes, by the way, you're talking about third-party resources. So should I use this third-party library because it's open source or this other one because it's closed source? Well, your code too is vulnerable. So we can't just look at somebody else and say, hey, you gotta make sure that yours is a locked vault without also looking at yours and talking about yours being a locked vault. Because often what happens is people say, I need to work with only open source because only open source is secure enough. I'm gonna put it in my closed source application. Well, yeah, but I I don't want to give away my company secrets and my company. So you're creating a black box and saying, but I don't want to use anybody else's black box. There's a little bit of a double standard there, right? So basing your security strategy on hope that a faceless group of people will do a security audit for you, that's a bad idea. Basing your security strategy on hope that you did it right is a bad idea. Hope in general is not a security strategy. So what you want to do is you want to have more of an actual plan for how to make your application secure, not just say, oh, well, open source is more secure. Now, there is one big exception to all of this, and that is authentication and encryption. So kind of like two exceptions. I really prefer to see authentication systems and encryption systems be open source. They greatly benefit from being open source. The incentives are there for the right people to validate and test for bugs and exploits. Plus, there's not a ton of them, and so it makes it a more manageable task. I mean, you think about it, how many resources are out there, third-party dependencies that your application can take? Let's just say just in C, if you want to look, go to NuGet and just start scrolling. Don't filter it, just start scrolling. You'll be there forever because there are millions of resources out there. So trying to expect that even the ones that, even the millions that are open source, expecting that they will be reviewed by somebody, it's not going to happen necessarily. But there are certain things that are more reviewed. And authentication and encryption are two of those things that are more likely to be reviewed. And you can even look and say, hey, who has reviewed this and what they find? So there's pluses and minuses to open source. Okay, it can be reviewed, but it's also easier to exploit because it's all right there. You can you can look at all the code. Now, on the other side of it, closed source, it's a little harder to exploit because it's a little bit of a black box, although again, you can decrypt and well, they can then obfuscate and there's a whole bunch of dance you can go around there. But closed source, you know, that's reviewed by less people, probably. Which means that it's probably possible to have more bugs in there. Again, who wrote the code? Is it great developers who have a great review team? Well, that's less likely to have bugs versus sloppy developers with a sloppy review team. Okay, even though the sloppy ones are open source. So there's really a balance here. So, number one conclusion we can reach from all of this, don't make a decision about security based solely on whether the software is open or closed source. That's foolish. It really is. Because just saying it's open source does not convey any additional security. Now, you could say, well, we can review it. Great. Have you? Have you really? Or have you just said we could? Have you just browsed through a few of the files, or do you actually do a real security review? Have you broken it down and trying to find every potential way of getting around it? You probably just looked at the code. And maybe not even that. So be careful of that. Be careful of any dependency that you take on. It doesn't matter if it's open source or closed source. The more dependencies you have, the the broader your attack surface can be. This is um something that you be very careful of, is just taking dependencies because it's easier. You know, for a long time, the entire industry for JavaScript depend on a little left pad library. All it did is do left pad strings. But since everyone depended on it, then there was tens of thousands of libraries that depend on that one little library. And that library had an exploit at one point. Well, there's a problem, and it brings down a whole bunch of our libraries. So that's a problem. Now, number three, evaluate every dependency on a case-by-case basis rather than on a blanket policy. So instead of saying, hey, you know what, we're gonna say all open source is okay. Or here's another one I find a lot. We're gonna say everything from Microsoft is okay, but nobody else. Why? I mean, I trust Microsoft for the most part. Um, and I don't think they're gonna do anything to exploit us, and I think that they are reviewing our code, and I think they do have great developers that are working on it. So, you know, it's a reasonable assumption, but just saying that everything from Microsoft's okay, that's not okay. And saying nothing from anybody else is okay, also not okay. That's not a that's not a wise thing to do. So having a blanket policy is unwise. You need to evaluate every dependency on a case-by-case basis. Yes, that means it's going to take more time to evaluate your dependencies. Good. Because you want to do that. You want to make adding dependencies a little tough, a little painful. Because if it's super easy, you just say, well, I'll just do this, I'll just do that, I'll just do this. As opposed to, ooh, I got to do some work on this. Maybe I just need two methods and I could just write those myself. Well, great. Write those two methods because that's a whole lot better than taking a dependency. It's gonna make your upgrade process easier too. All right, number four, understand that all of software development is risk management. So even your own software increases your risk. So if you think of it as we're secure, we need to make sure everybody else is secure, that's not great. If you think we've got to make sure that everything is secure, great. You've made a step in the right direction. If you're evaluating your software as strictly as you're evaluating everybody else's, that's a really good thing. If you're taking your code on a case-by-case basis rather than just doing a rubber stamp check mark for every pull request, that's a good thing. So making sure that you manage your risk. You will always have risk when you write software. Whenever you almost every piece of software in the world deals with data. And for most companies, that data is their lifeblood. So when you write software, you'll be directly interacting with the most vital part of your company. That's a scary proposition. And it's something you need to treat very, very seriously. And so you need to be thinking about what your code does as well and making sure that you aren't doing something to make your code more vulnerable. I've seen lots of people who have left their database vulnerable with their code and then been overly cautious about somebody else's code. So make sure that you're working through that and balancing checking somebody else as well as checking yourself, making sure that you're doing a lot of reviews because it's all about risk management and allowing no risk in one area, but doing nothing to mitigate risk somewhere else is just unwise. Okay, so those are my thoughts. I hope that's helpful. Thanks for listening. And as always, I am Tim Corey.

SPEAKER_01 13:41

Thank you for joining us for this episode of Def Questions. Tim is committed to making it easier for you to become a developer. If you would like to help make more content like this possible, please like, subscribe, rate, and share Deaf Questions. You can also send your questions to questions at IamTimcorey.com. Until next time, remember, you are too smart and your time too valuable to waste it making all the mistakes Tim did. When you're ready to learn to think and code like a professional developer, head over to imtimcore.com and enroll in a course.