Open-source software (OSS) is the foundation for most platforms built today. It’s hard to imagine any software product in today’s world not using OSS. But is OSS more secure?
There are always inherent risks with any usage of OSS, but a few best practices can help reduce these risks.
OSS has published sources, and even though having a published source doesn’t automatically make it secure, there are millions of OSS components available. Obviously, only some OSS gets high usage and contribution from developers.
If you’re looking for an OSS component to use in your software, what should be your criteria?
Community
Most of the security of OSS comes from the community around it. The more people who use it and address the issues, the more stable and secure the product is. Not all open-source components get the same level of attention.
When picking OSS components, always look at the community and see how actively it’s being developed and how many contributors are actively involved.
Reviews
Secure software needs to have good reviews in place for reliability and security. OSS is no exception. Look for the review practices adopted by the OSS component. Someone who might want to insert malicious code is less likely to do so if more eyes are looking at it. Stay away from components where changes can be made without review.
Response to security issues
It’s always better to look for known security issues before picking an OSS. Look at how the community responds to security issues. Look for components with a community you can contact for security problems, especially if they offer quick responses.
Consuming open source
Oftentimes, a component is used just for consumption, and the organization may not have the expertise to contribute to it. If you’re treating the component as a black box, have a plan to reduce risk. Always try to have a wrapper around the black box component and validate/sanitize what you pass to the component. Having predefined and validated set of inputs and scenarios can help you avoid the risks associated with not knowing how the components behave.
Scans
It’s always important to scan for security issues—make sure you include OSS scanning tools or build your own monitoring for Common Vulnerabilities and Exposures (CVEs) as a continuous process for any open-source components.
Stability
Always pick up a stable version of the software—OSS keeps changing and staying on a bleeding edge might be risky for the stability and security of your production environment. Additionally, make sure you keep patching any security issues popping up. You should also have a plan to upgrade the components to the next stable releases whenever they’re available.
Local builds
Always pull the code from trusted sources and build it locally. Avoid getting binaries from untrusted sources. If you use binaries, get them from well-established publishers and verify signatures or hashes beforehand.
Dependencies
Watch out for dependencies, as components might have implicit dependencies. Follow a similar process for every dependency.
Even well-maintained sources like Linux with multiple levels of reviews and enforcement have gotten close to including malicious code. But fortunately, the practices they adopted eventually caught the issues.
