How Do You Secure Open Source Software?
Executives and experts advise that develoeprs follow best practices, test, and choose the most recent version of the code.
Join the DZone community and get the full member experience.Join For Free
To gather insights on the current and future state of open source software (OSS), we talked to 31 executives. This is nearly double the number we speak to for a research guide and believe this reiterates the popularity of, acceptance of, and demand for OSS.
We began by asking, "How do you ensure the security of OSS?" Here's what they told us:
- Have an automated bill of materials and upgrade versions of open software when new versions come out.
- Building open source software is in many ways more secure than proprietary software because you have multiple people testing and contributing to it. If you have an open source project, you obviously have to be cautious and careful about what code contributions you accept. There should be a governance process and reviews related to any open source contribution. From a security standpoint, you obviously don't hardcode tokens, keys, etc., and you enable a bring your own key model for encryption.
- There is no inherent problem with the security of Open Source Software that isn't a problem with software in general. We just found out the not-open source microcode in nearly all of our processors has a vulnerability which allows you to hack into another VM running on the same host (i.e. hack into someone else's AWS instance potentially) and its been there for years! How do you ensure the security of that? As an industry, we need to think more about security as a set of policies and procedures that have to be in place as a form of quality control as opposed to nonsensical audits and treating breeches like they're unlikely as a 100-year storm.
- All code has vulnerabilities. In open source, it will be discovered, identified, and communicated back to the project maintainers. Have a process to report issues and contribute patches. Integrate fixes into releases every two weeks.
- Security’s an ongoing process. You are never done with this, and it requires—I want to quote Mad-Eye Moody here— “eternal vigilance!” You always have to look at what you’re doing and make sure the systems you’re using to share that open source software are themselves secure, so you know you can trust how you’re communicating with people. The platform you’re using to share the code has to be secure to begin with. Then, you look at questions like: Is the code I’m using good?; Does it have bugs in it?; Are those bugs accidental or malicious?; How do I know? It’s a constant evaluation. There’s a web of trust that is, in reality, how all of us in the computer industry work day-to-day. We must trust people and the provenance of the code that we get from one another. For example, every single one of us trusts Linus Torvalds to do a good job with the Linux kernel and not to put backdoors in it. If he did that, many people would be in trouble. But we trust him, provisionally, and we keep verifying that trust. That’s how it works for everything. When it comes to how to reinforce, or increase, that trust, my obsession right now is with package signing, that is, verifying that the code an open source developer distributes is the same as the code that you end up using—that it hasn’t been manipulated or interfered with by a malicious actor.
- Use the same techniques for all software. Solid code review. The open source community has more innovative software to check for threat vectors. Open source has a huge advantage with the number of eyeballs on the projects. Something that checks for common vectors.
- We work very closely with customers to ensure our software complies with information assurance policy standards. Our software is running on the networks of Fortune 500 companies, and within the secure, classified networks of the United States Federal Government. Our software integrates with users’ identity management systems (Active Directory, PKI, etc.) to ensure access to data and services is respected.
- We use a combination of approaches. The first is the absolutely necessary step of manual auditing via code review. The second is automated monitoring of CVE databases and integration of those results into our continuous integration pipeline. Last, we use fuzzing to find vulnerabilities that would be very difficult to find with testing or code review. All told, these approaches can be quite time-consuming, but to maintain a solid security posture they are all necessary.
- Vulnerability scans with results published every time code is committed.
- It may come as a surprise to say that open source software is more secure than any closed software since it is open to review by researchers, businesses, and users to report. However, because the software has a community that is looking to address bugs and security vulnerabilities, it allows security concerns to be addressed quickly. The nature of the software also allows third-party and independent entities to audit and test the software for vulnerabilities.
- Security continues to be an enormous challenge for open source as there are hundreds of ways to check for security. I think the problem is likely to be solved and owned by the source code management (SCM) vendors like GitHub or GitLab who are starting to integrate it right into the development process. In fact, we can see the source code management system starting to be the fundamental control plane for quality in the development process, with richer testing and verification tools built right in. GitLab is one of the leaders in this strategy but we can expect others to follow.
- There are a couple of ways of ensuring security, first is adopting strict coding standards and guidelines, as well as ensuring that the parts of the code that access critical resources are written with utmost accuracy and checks. Second is enforcing a strict security testing practice after every check-in. DevOps strategies, that automate checkout, build, test, and deploy, coupled with the right vulnerability scanning tools, come in handy with this strategy.
- More secure than closed source because everything is visible. We encrypt data in flight and perform security reviews to ensure data is persistent. Run the most up-to-date version of the software to be 100% secure.
- It is important to know what you’re using, make sure you’re using the latest appropriate version and, if possible, perform your own security scanning. Participate in the component’s development ecosystem if it’s a major part of your product and encourage behavior by the developers to build quality into the software. Encourage selection of components from organizations with a culture of quality and spot check components that may not be. Dedicate time or money to testing important components and, if possible, help the original developer with complicated reviews.
- OSS is more inherently secure than other code due to the number of people looking at it. It's better quality and developers are able to discover and fix vulnerabilities quickly.
- As projects get a big enough developer base, bugs will be identified and fixed. Open source is more secure than commercial. Developers are encouraged to find issues and bugs.
- Frequent updates and patches. Open source is inherently more secure because more people are looking at the code. Make sure you are using the most popular code as it is less likely to have undiscovered vulnerabilities.
- It's no different than private software. Open source has more eyes looking at it. Similar to enterprise software. Know what’s coming from the owner of the software and that you can trust it. Make sure you get the same of what’s on the website. Verify what you get is coming from the original company.
- Enterprises have made long-term investments in their security stack, including investments in products, technologies, and processes. All of these and more took decades to put together. A lot of security issues are governed by laws, so security is not optional. Security in open source is as primitive as those used by enterprises. Given the fast-changing and innovative nature of open source, it can be risky to migrate from the current security system within enterprises to a security system in open source. This is where the third leg of open source comes in, namely a set of software that hardens and provides an integrated stack. Enterprises need glue logic that actively integrates with their security infrastructure and delivers enterprise-quality from the security perspective.
- The same way we ensure the security of anything: hard thinking and hard work at all levels. Security threats are growing more sophisticated by the day and come from all sorts of vectors. Our security team takes good care of influencing early design decisions in all our architectures.
- The Apache Software Foundation has a dedicated security team dealing with security. When a security breach is found, it is flagged, announced and fixed immediately, then shared publicly in a timely manner.
- As a company that builds on open source software, we use industry tools to check the software and its libraries for vulnerabilities.
Here’s who shared their insights with us:
- Anthony Calamito, Chief Geospatial Officer, Boundless
- Jakob Freund, CEO, Camunda
- Pete Chestna, Director of Developer Engagement, CA Veracode
- Julian Dunn, Director of Product Marketing, Chef
- Matt Ingenthron, Senior Director of SDK Engineering, Couchbase
- Stephan Ewen, Co-founder and CTO, data Artisans
- Amol Kekre, Co-founder and Field CTO, DataTorrent
- OJ Ngo, Co-founder and CTO, DH2i
- Stefano Maffulli, Director of Community, Zenko
- Kelly Stirman, CMO and VP Strategy, Dremio
- Konstantin Boudnik, CTO Big Data and Open Source Fellow, EPAM
- Tyler McMullen, CTO, Fastly
- Jeff Luszsz, VP of Product Management, Flexera
- Angel Diaz, V.P. Developer Technology and Advocacy, IBM
- Ben Slater, Chief Product Officer, Instaclustr
- Grant Ingersoll, CTO, Lucidworks
- C J Silverio, CTO, npm
- Mark Gamble, Senior Director of Product Marketing, Analytics, OpenText
- Francis Dhina, CEO, OpenVPN
- Sirish Raghuram, CEO and Co-founder, Platform9
- Neil Cresswell, Co-Founder, Portainer.io
- Lars Knoll, CTO, Qt
- Brad Adelberg, Vice President of Engineering, Sauce Labs
- Giorgio Regni, CTO, Scality
- Dor Laor, CEO, ScyllaDB
- Harsh Upreti, Product Marketing Manager, API Products, SmartBear
- Jean-Baptiste Onofre, Technical Fellow and Software Architect, Talend
- Antony Edwards, CTO, Testplant
- Matt Ellis, Architect, TIBCO Software
- Karthik Ranganathan, Co-founder and CTO, YugaByte
Opinions expressed by DZone contributors are their own.