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:

Best Practices

• Have an automated bill of materials and upgrade versions of open software when new versions come out.
• Because open source software has more eyes on it, it’s more likely that vulnerabilities will be seen, and resolutions provided. It’s important to measure how quickly you are able to update code once a vulnerability is identified. It should take just a few days or hours.
• Since the code is all in the open, it is easy to do an architecture and code level security audit. Because there are many users deploying and securing the software, it should be easy to find out the best practices to ensure it is deployed in a secure manner. If there are features missing, asking for that feature or up-voting that feature if its already being considered is a real option to get it implemented.
• Security, like the other aspects of quality of open source software, is a community effort. There is a security vetting and testing process for each project that is out in the open, and users can judge whether this is sufficient for their needs. In addition, you can be aware there is a community of users who are constantly evaluating and testing the security of these products and will provide feedback in fixes for any issues found. Of course, you should also be a responsible citizen and report and ideally fix any issues you may find (and if you are large user bases or have particularly strict security requirements, take some responsibility for helping test and improve the security of the products on which you rely!).
• 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.

Test

• Vulnerability scans with results published every time code is committed.
• Research, test, read the licensing carefully. Some packages require you to publish your source code and this can expose your entire solution. You have quicker access, but you need to be aware of the requirements.
• 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. 
• Open source software as a whole is much more secure than closed, proprietary software since there are eyes on it beyond those of the authors. In broader terms, there is always the need to test security, and to audit dependencies (open source or not) to make sure that they are both secure and functional. The software being open source does not change this in any way except to broaden the potential pool of developers who can fix issues.
• 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.

Version Knowledge

• 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.

Other

• 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.