How To Secure Open Source Software
How To Secure Open Source Software
Open source software is said to be more secure because of its community of developer contributors who follow best practices.
Join the DZone community and get the full member experience.Join For Free
Open Source Software (OSS) is a type of computer software whose source code is available for anyone to use, inspect, modify and enhance. This code is released under a license which permits users to use, modify or distributed to anyone for any purpose. Though OSS are freely available to anyone for use, there are various OSI approved licenses under which this software gets published.
In any computer software, whether it's Open Source or Closed Source (proprietary), there is always a possibility for security vulnerabilities to exist. As of now, there are no statistics which prove whether OSS or CSS is more secure, which means we cannot conclude which type of software is more secured. However, many people think that OSS is more secure since the source code is open, editable, with a large number of testers, a developers base, and community-based peer review so almost every problem will be caught, and the fix will be given by somebody. Since the source is open and editable, any attackers or criminals can add some code which can cause vulnerabilities.
We should keep in mind that security vulnerabilities are not same as bugs. Bugs are usually founded when software does not do what it's expected to and it's easier to catch bugs than security vulnerability. In this article, we will talk about OSS vulnerabilities and a few best practices to deal with these.
Open source vulnerabilities pose significant risks to application security. Many development teams rely on open source software to accelerate delivery of software solution. Both traditional and Agile development processes frequently incorporate pre-built, reusable open source software components. But most open source software is not subject to the same level of scrutiny as software that is custom developed. OSS comes with natural risks; you don’t know who you’re downloading from, and the security standards of maintainers. Open source vulnerabilities could potentially expose an organization to threats such as malware injections, data breaches, and Denial-of-Service (DoS) attacks. One of the most notable breaches of 2017 was the one suffered by Equifax, resulting 143 million Americans' information was exposed and was in risk. The breach was accomplished by exploiting a known vulnerability in the Apache Struts2 (a framework for creating web applications written in Java) package that made it possible for a remote attacker to send a malicious request that would allow them to execute arbitrary commands.
According to the Veracode’s State of Software Security report, 70% of applications fail to comply with basic enterprise security policies, such as OWASP Top 10 and CWE/SANS Top 25. However, while developers test their own code regularly and rigorously, and would immediately tend to fix security vulnerabilities, most are paying little attention to the open source libraries that ship with their products though, in one of the Open Source Surveys conducted by Github, 86% of users said security is extremely or very important.
To address the risk of open source vulnerabilities in the software supply chain, groups such as OWASP, PCI, and FS-ISAC now have specific controls and policy in place to govern the use of open source components.
Let us now see a few best practices to secure OSS:
- While choosing OSS, look for a company and team which has a proven record of delivering quality product, fixing vulnerabilities as quickly as possible and have a record of responding to any query, help or reported issues. Also, look at how contributions are evaluated and included.
- Have a clear security policy which contains clear guidelines about the installation and maintenance of open source. This policy document should be available to everybody and need to make them have a good understanding of these policies. There should be a dedicated team consisting of a system, network, and security administrators, which are responsible for implementing the policy, ensuring that the policy is strictly adhered to and revising the policy as the business needs change.
- Always be on the latest version of the software. Whenever a new version gets released, upgrade to it. Since OSS is open to everyone, releases are expected to have more frequency, and each version might contain vulnerability fixes. As per White Source, 85% of software projects use outdated libraries. This happens due to time constraint, lack of understanding of the need of an upgrade, risk in breaking existing features, etc. As open source works on a "pull" support model, users are responsible for keeping track of vulnerabilities as well as fixes and updates for the source they use. In many cases, organizations often don't have visibility to all of the open source components they use and because of which few components remain unpatched/un-upgraded. An organization must encourage developers to keep eyes on release notes and upgrade as frequently as possible.
- To avoid potential risks from pre-inserted malicious code, download OSS only from trusted sites like official sites of a developer(s), verify against MD5/SH-1 provided checksum against downloaded source code and prefer downloading source instead of a compiled binary package.
- Always read the documentation carefully before installing or start using any OSS for any explanation of the secure configuration parameters.
- You must be cautious and careful about accepting any contributions if you have an open source project. You should have proper guidelines and review process for any contribution.
- Motivate teams including developers, security, dev-ops team to keep up to date with vulnerabilities logged in online or offline sources like National Vulnerability Database (NVD), project distribution sites such as those maintained by the Debian and Python projects, security blogs and message boards such as the US-CERT alerts page and Google's security blog so that necessary action can be taken.
- Let security team work with other teams like Dev, QA or Dev-Ops so that security team can help other teams in understanding security concerns and its importance.
- When any team wants to start using any new OSS, let security Subject Matter Experts look up to the software and find out if there are any publicly known vulnerabilities exists. If so, it doesn't make sense to start using this software and intake vulnerabilities since there are plenty of unknown vulnerabilities are floating around.
- Putting checks only on incoming software does not help us in finding vulnerabilities in existing codes. Also, putting a check for incoming software doesn't mean that no vulnerabilities will get in. So, we should be scanning all source codes to detect existing vulnerabilities. There is a number of free (FindSecBugs, RIPS, Flawfinder, SonarQube etc.) and paid (Veracode Static Analysis, PVS-Studio, bugScout, SecureAssist etc.) source code scanner available. An organization can choose which one to use based on tech stacks, resources, and budget. One good idea will be doing some POC(Proof Of Concepts) with these tools and decide which one to use. These kinds of tools usually identify publicly-known vulnerabilities. Scanning processes need to be repetitive, they must run periodically. An organization can decide how frequently they want to run this. Integrating with build tool will report vulnerabilities much ahead if we run only before release. For a small organization with few applications, they might think of implementing own scanner. Though these tools can help, they cannot substitute for security training and knowledge and will never match an expert auditing the source manually for security vulnerabilities.
Flawfinder site rightly mentions:
"A fool with a tool is still a fool."
- Once we have a list of OSS to use in any organization which is already approved by Security SMEs, it will be a good idea to maintain these software's names, versions and let the developers aware of this so that they always use the approved software (with version).
- OSS, like any other software, may require the opening of specific ports (TCP, for example) for Internet access. We should be very careful doing this so that doing so does not open other security holes in the network. Also, it's important that OSS is compatible with existing network security architecture. If adopting a given open source application or software requires radical changes to existing architecture that could compromise network's security, we might want to reconsider whether it's right for the company and look for alternatives.
- As a maintainer, we should have a public-facing disclosure policy so that user can report vulnerabilities as soon as they find one. When a security issue is addressed, clearly present users with detailed information so they know exactly how to proceed.
- Contributing back is one of the best ways to ensure OSS projects stays secure and bug-free. Maintainers are working hard to make their projects better but as a good citizen, we should start contributing however we can, instead of waiting for them to fix everything for us.
- We should be more responsible while reporting any vulnerability. Letting the maintainer in a private way instead of making it public. Apart from this, vulnerabilities can be reported on sites like rubysec, Snyk. Apart from these sites, adding information in release notes, filing CVE (Common Vulnerabilities and Exposures) or depreciating the version can also be used for this.
The use of open source software is booming, irrespective of ecosystems. Organizations all over the world, from every vertical imaginable, use the open source code to power their businesses and that's why security is one of the top concerns. So, to deal with this concern, we should make these best practices (along with others which are not covered here) as a culture of the organization. Also, let us know in the comment section of this article as and when we come across with any other best practice.
Opinions expressed by DZone contributors are their own.