Google announces funding for an open-source maintenance crew

Recently, Google announced that it will be funding a new initiative that will seek to improve the security of the most important open-source projects. What challenges does open-source software present, what will Google be doing, and what should engineers consider when using open-source software?

What challenges does open-source software present?

Ever since the development of the first computer, the battle of closed-source vs open-source continues to rage on. While each side will throw accusations at the other and claim that they are in a better position, the truth is that both sides have their own advantages and disadvantages. For example, closed-source software has the advantage that vulnerabilities in the software are hard to find as the code is not open to the public, but this means that when vulnerabilities are discovered, it is up to the source-code owners to fix them. On the side of open-source software, it has the advantage that it is free for anyone to use, but this leaves it exposed to hackers who can find vulnerabilities faster.

But when looking at the technological landscape, open-source solutions are taking the lead, most likely due to their lack of royalties, licenses, or fees. At any given moment, there are thousands of start-ups worldwide developing all kinds of software-driven projects. Considering that such start-ups typically have limited budgets, using pre-made open-source libraries and software solutions makes far more sense than finding obscure companies who sell proprietary solutions. Additionally, open-source communities are generally active, allowing engineers to ask the public for help.

However, the widespread use of open-source software has also introduced some very serious challenges, including security. As we discussed previously, open-source software can be exceptionally vulnerable to hacking as the source code is freely available, but this also means that vulnerabilities can be more easily spotted by the public and reported. In theory, this should see open-source projects patch vulnerabilities much faster than proprietary code, but this is not always the case.

Open-source projects can themselves consist of many other open-source projects, and it is entirely possible that a large open-source project (such as Linux) can include libraries and code from other projects that are far less popular. Thus, security vulnerabilities that exist in these smaller libraries may go unnoticed and getting a fix for such vulnerabilities may be challenging if the original project is not well maintained.

Google announces creation of Open-Source Maintenance Crew

Recognising the challenges presented by open-source software, Google has recently announced that it will be funding a special task group whose sole purpose is to help maintain the security of popular open-source projects. Considering that large portions of modern life are being powered by open-source projects, ensuring that vulnerabilities are identified and patched quickly will help strengthen the security of any device using popular open-source code.

The announcement was made during the White House Open Source Security Summit, where large tech firms including Google, Intel, Microsoft, and Amazon jointly pledged over $30 million to tackle the issue of security in open-source code. Also announced was the Software Supply Chain Security Mobilization Plan, which seeks to help educate those in the open-source community on software standards and security and perform annual reviews of the top 200 open-source projects.

However, it was also announced that the new plan will aim to move open-source projects away from vulnerable coding languages such as C and C++ to memory-safe alternatives, including Rust and Java. This is particularly interesting as many vulnerabilities take advantage of poor memory management or lack of boundary checking of arrays, such as the SSL Heartbleed attack that took advantage of buffer overflow to observe the contents of protected RAM.

What should engineers consider when using open-source software?

Open-source projects can save engineers hundreds of hours of coding and cost nothing, which is why their use makes sense. However, open-source solutions also open up a design to vulnerabilities that hackers will learn about very quickly, which is why engineers should take some precautions when using open-source code.

Firstly, a device that uses open-source code must have the ability to install updates, and security updates must be compulsory. How these updates are installed depends on the device, but end users must have access to a mechanism whereby they can be informed of potential vulnerabilities (whether it is through an email list or notice message on the device itself).

Secondly, engineers should be aware of the complete list of open-source code used in their projects. A new concept that is coming out, called Software Bill Of Materials (SBOM), describes every software component used in a project. For example, if Linux (an open-source project) uses an I2C library made by someone else, the SBOM for that Linux distro would include a list of all other projects used, including the I2C library. If engineers can procure such a list for all software used, it can help identify potential vulnerabilities of libraries that may not be obvious.

Thirdly, engineers should avoid using solutions that have no active support. Smaller libraries that interface with a specific device will likely be frozen in development as there are no other functions to improve on (such as an I2C temperature interface), but projects relying on a large open-source platform or solution (such as an RTOS), should have many active members, frequent updates, and code suggestions.

Overall, open-source solutions have helped to accelerate projects significantly while simultaneously standardising coding practices. However, the security threats that they provide must be taken seriously, and engineers must be aware that large open-source projects may incorporate many other smaller projects that themselves may introduce vulnerabilities.