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: www.iamtimcorey.com/
Ask Your Question: suggestions.iamtimcorey.com/
Sign Up to Get More Great Developer Content in Your Inbox: signup.iamtimcorey.com/

[@opietwoep1247]

Amazing video. What I would give to build a Time Machine and take you back to some of the meetings I was in trying to say what you just said in such a clear and understandable way. Keep up the great work.

[@IAmTimCorey]

Thank you!

[@faisalalhoqani6151]

Great insight into security perspective. Thank you, dear Tim, keep it up.

[@IAmTimCorey]

You are welcome.

[@rendellgood]

Another great video topic! Thanks!

[@IAmTimCorey]

You are welcome.

[@BlueIced256]

Although I do agree with you what you are saying here, I still think it is too focused on reviewing code. There are 2 things, I like to mention that you didn't address or at least very limited. Of course code review is very important, but the patch cycle is at least as important. Theoretically that should be possible to be done a lot quicker in open source software than in closed source. Because in open source everybody can make that patch. But in the end it depends on the popularity of the product and the quality of developers. With closed source, it all depends a bit more on company politics and the priorities. On the other hand, closed source usually has a better code review after a patch is made. The second issue you didn't talk about, and that is the reason why I tend to have preference for open source, is that closed source might gather more data about your usage of the software and in some cases more information than that. This is beneficial for a software company to improve their products, but also means you have to rely on that company that they use that data properly. In open source it is a lot harder to retrieve that kind of information as people can fork the code and remove the parts they don't like. In the end it is all about preferences and priorities in selecting a product. It is our responsibility to make conscious decision about what product we use.

[@IAmTimCorey]

I think that's more theoretical than reality. For example, even at the Microsoft level there isn't a lot of people adding patches. Mostly it is Microsoft employees. At the smaller OSS project level, a lot of people are getting their PRs ignored because merging the PR will add a burden to the OSS maintainer. As for the tracking of the usage, I think it is very easy for OSS to do that (and a lot do). What you need to remember, though, is that a lot of OSS isn't the entire system, just pieces. When you are referring to closed-source projects, you are talking about complete systems. That's a bit of an apples to oranges comparison.

[@BlueIced256]

@@IAmTimCorey I don't agree on that. A component that researchers use to express how secure software is, is the patch rate. I remember that in the passed MacOS was considered very secure because there few leaks and bugs in the software, but their rate dropped because of terribly long patch cycle. The reason is that the longer a known issue exist, the longer you are vulnerable for attacks. Compare it to a house. If you build a house with no locks and nobody knows, you most likely will have very few burglars coming in. But when it becomes public knowledge, they are practically in line to access your house. The only thing you can to prevent that is to add locks to all your doors. I am not sure if you remember the log4j issue from a couple of years ago. That problem was there for years unknowingly. But when found it was patched very quickly and the entire world was patching their systems. For smaller OSS projects there is of course a resource issue, for closed software there are political and financial decisions made... But bigger OSS projects have usually contributors from companies like Microsoft, Red Hat, Google and such. Not just small companies or individual developers. Regarding data collection, the best example is probably VS Code. Microsoft has a lot of tracking software in there. Some developers didn't like that and they forked the project. They made a version without the tracking software and called it Codium. Same thing for Google Chrome and Chromium. Code reviews are a proactive way to prevent bugs. But like you said yourself that doesn't mean there will be no bugs in the software. Therefore patch cycles are just important as the reviews. That PRs are ignored by both OSS and CSS projects for many reasons. With OSS it is often done because of the burden and the limited time developers have, like you mentioned. With CSS projects it is often done because of commercial reasons. E.g. the software company wants to release new features, because it will gain a competitive advantage and/or creates more revenue.

[@KREKER8331]

Hi Tim. Thank you for your content. I have a question about your courses. In your courses are also practical part like some assignments to do?

[@IAmTimCorey]

Yes, a lot of my courses have homework or challenges to complete. What I don't often provide is the "answers". I push people to treat the homework like they would a real-world assignment. They have the requirements. They have the training. Now they just need to put it all together. I especially focus on homework in my Mastercourses and in my Accelerate courses.

[@KREKER8331]

​@@IAmTimCoreyThank you, great.

[@runtimmytimer]

I’m glad MS finally added the ability to see NuGet packages with vulnerabilities in VS. I wrote PS code for a CI/CD pipeline in Azure to identify them during a build. It shows outdated as well as vulnerable packages.

[@IAmTimCorey]

I'm glad you like it.