What is FOSS?
Free and Open-Source Software (FOSS) is software that is distributed with a license that allows users to run the software for any purpose as well as to study, change, and distribute it freely. Often, a particular piece of software is available open-source at no cost, but the company that maintains it charges a fee for support or for more advanced features that are not open-source.
Some FOSS is a complete application that can be installed and run on its own. But many sub-components are released as FOSS, and are embedded in other applications. For example, many web applications use a framework like AngularJS to streamline their user interface code, or a database like PostgreSQL to store their users’ data.
Using FOSS components can accelerate the development of new products, and can also make software more secure and robust by increasing the number of people contributing to each component. In fact, the foundations of the Internet are built on open-source software and standards!
How HighGear Uses FOSS
At HighGear we use third-party components (both closed-source and open-source) frequently but judiciously. If we can create better functionality or an easier user experience by writing everything ourselves, we do that. HighGear uses many well-known open technologies, like React, C#, and CKeditor, as well as smaller components that fill specific needs. We choose our tools and components (whether FOSS or commercial) based on many factors, including security, reliability, quality, performance, and the trustworthiness of the teams that maintain them. When we find a tool or component that lets us deliver value to our customers faster, we are happy to do that.
We also contribute improvements back to the FOSS components we use. That is one of the great strengths of open-source software: when one user fixes a problem or adds a feature, all other users can take advantage of that improvement.
The Risks of Using FOSS
As you can see, FOSS has many benefits for HighGear and its users. But there are some risks that must be carefully managed. The most well-known is the “viral license”. Many FOSS components use the GNU GPL or a similar license that require all users of the software to release all of their own source code under the same FOSS license. One well-known example is Tesla, who have been forced to release the source code for some parts of their autopilot systems. As a commercial product, HighGear must be careful to comply with the license terms of every dependency we rely on. This is also important to our customers, who want to be sure that we won’t be entangled in a lawsuit over license violations.
All software includes a risk of security vulnerabilities. In some ways FOSS is safer than closed-source software, because more people can review the code and fix problems. But on the other hand, it is easier for attackers to find vulnerabilities in open-source software, because they can simply read the source code and look for problems. Overall, it seems that closed-source software and FOSS have roughly the same risk of security issues.
A risk that is unique to smaller FOSS projects is that of the malicious maintainer. Commercial software providers and large FOSS organizations have the resources and the incentive to vet their employees/contributors before allowing them to write code. But smaller FOSS projects are often resource-constrained and happy to accept help from anyone who offers it. This has led to a number of cases where an attacker gained the trust of a small but widely-used FOSS project and then quietly inserted malicious code into that project. In one example, a commonly-used component called “event-stream” was modified to secretly steal users’ Bitcoin wallets when they logged in to an app called Copay. Thankfully, the attack was detected before it could be targeted at any other applications that used the component.
A final factor that makes all of these risks harder to manage is the way that many FOSS projects depend on other projects, which in turn have their own dependencies. This means that using one FOSS component can cause tens or hundreds of unexpected software modules to be downloaded. This makes it difficult to keep track of all the licenses, security patches, and maintainers that are involved in a product’s codebase.
How HighGear Mitigates the Risks of FOSS
The foundation of our risk mitigation plan is automated dependency management and auditing. We use Sonatype Nexus to monitor all our dependencies, enforce our policies, and scan for security vulnerabilities. To enable us to verify that our software complies with our legal and security policies, Sonatype traces the dependencies we rely on and produces a Bill of Materials (BOM) report. This report lists every component used anywhere in HighGear’s dependency graph, no matter how small.
To ensure that we don’t accidentally use a component that carries a viral license, our management team maintains a list of approved FOSS licenses. This list is used to validate each new component that we consider adding to our software, as well as any components they depend on (and things those dependencies depend on, and so forth), and it is also used to set policies in Sonatype.
In addition to security vulnerabilities listed in the National Vulnerability Database published by NIST, Sonatype’s Release Integrity system also uses AI and ML to automatically block dependency attacks relying on malicious code injection. This system allows us to detect and block security problems even before the vulnerabilities are published.
If any component or dependency is found to have a non-approved license or a security vulnerability, an alert is immediately raised and the HighGear software cannot be released until it is resolved. Sometimes the resolution is as simple as installing a new patch with a security fix. In other cases a fix is not yet available, and we must find a way to mitigate the problem until a fix is released. If the problem remains un-fixed, we may submit a fix back to the component’s maintainers ourselves, or replace the vulnerable component with a different package that is not vulnerable.
It is not enough to react to problems after they occur. To proactively avoid problems, our product management team also reviews all new FOSS components that are suggested to be added to HighGear. We consider the component’s value proposition, license, history, activity level, the background of its maintainers, and its compatibility with our existing technical stack. Only components that show clear benefits and low risk are used in HighGear.
What is Next?
The security and reliability of FOSS software has been a top concern for IT departments and business leaders for 15+ years, but their concerns focused on the visible software: operating systems, office suites, etc. The security of the components hidden inside purchased software has been mostly ignored until recently. Fortunately, many vendors saw this emerging need and have built Software Composition Analysis and Open Source Governance products that are now mature and widely available. We expect that like HighGear, other software vendors will begin to use these products in conjunction with defined policies and processes to mitigate the risks of their FOSS dependencies. As this practice spreads the result will be increased security and trust, which is essential for the software industry and its customers.
Conclusion
FOSS is an essential part of the modern technical landscape, but it also carries risks that are not fully mitigated by traditional security policies. At HighGear we have implemented policies, processes, and automation to mitigate those risks. Our customers expect us to provide a trustworthy enterprise-grade solution, and we will deliver that. Do you have any questions about our processes? Suggestions about how we can make it even better? Please comment below.
