Open Source in Application Development: Safe or Total Thermal Nuclear War?
Are open-source software tools safe to use in application development?
Truthfully, it is challenging for a general consumer to know if a developer has knowingly or unknowingly introduced a vulnerability in a piece of software that you are looking to implement into your organization. The same holds for an application developer who is contemplating integrating third-party code into their product.
Most open-source software is made up of other third-party components through direct and transitive dependencies, thereby expounding the potential risks to the final product. One added third-party component could have its own added third-party component, which could have its own added third-party component, and so on.
Direct dependencies are the libraries your code is calling to and transitive dependencies are the libraries that your dependencies are linked to – basically, they are dependencies of dependencies.
- WhiteSource.com: Why Open Source Dependencies Are Your Blind Spot?
Most developers will host their project source code in a code repository, one of the more popular being GitHub. According to GitHub's 2020 Octoverse report, 17% of vulnerabilities were explicitly malicious but triggered just 0.2% of alerts.
It won't happen to me, right?
On March 28th, 2021, two malicious code commits were pushed to the PHP Git repository. PHP is a scripting language that at the time of writing this article, is used by 78.5% of all websites recognized by W3Techs. The commits were attributed to Rasmus Lerdorf, the creator of PHP, and later Nikita Popov, a maintainer. The malicious code included a backdoor that would execute code from within the useragent HTTP header of infected servers. The code was first pushed with Lerdorf's attribution, found and reverted by Popov, restored by criminal seven hours later this time attributed to Popov, survived for one more hour before being removed permanently. During the 8+ hours that the infected code lived in the PHP code-base, the infected version of PHP was available for consumers to download.
The post-incident investigation pointed toward a compromise of the git server and not the individual accounts. The remediation actions led to the decommissioning of the git server and migration to the cloud-hosted GitHub platform that provided better granular permissions and multi-factor authentication.
How do I know what's in my food?
If you go to a grocery store and buy any food item, you can easily find a list of ingredients on the package used to create the product. This same concept has been applied to the world of technology in a software bill of materials (SBOM). Per the US Department of Commerce: National Telecommunications and Information Administration (NTIA) an SBOM is
A “Software Bill of Materials” (SBOM) is effectively a nested inventory, a list of ingredients that make up software components. The following documents were drafted by stakeholders in an open and transparent process to address transparency around software components, and were approved by a consensus of participating stakeholders.
An SBOM will be comprised of data fields; information that describes the components, automation support; reporting formats for transmission across organizational boundaries, and practices and processes; describe when and how the SBOM should be updated and delivered.
Effectively this will provide details on all the nested components that make up a product. Unfortunately, that could be 100's of core components, which would be burdensome to manage when monitoring discovered vulnerabilities and patching requirements on nested products.
An organization would pair the SBOM's with a vulnerability scanner software to continuously scan the SBOM components and compare them against known vulnerability databases to detect any potential issues.
Additional software to assist with vulnerability discovery are tools called Software Composition Analysis (SCA). These tools will identify software on your network, scan source code, manifest files, packages, and other items and then compile them into a digital Bill of Materials (BOM), which is then checked against multiple databases for know vulnerabilities. The benefit of this is that the BOM can be generated at any time and routinely verified and audited.
A cybersecurity executive order signed by the Biden Administration on May 12th, 2021, states that SBOM's will be required for organizations that do work with the federal government.
What if I don't have money to buy that?
One of the reasons many consumers are attracted to open source applications is the low, low cost of zero. This same reason may result in these consumers not having the budget to purchase an SCA, so what should they do when evaluating whether to use an open-source product.?
I would use the same judgment you would when buying any retail item.
- What are the security requirements for the environment where your application will live?
- Is the manufacturer reputable?
- How long have they been producing this product?
- What do others have to say about them?
- How often do they release updates?
- Does the product have an active community of users?
- What is the makeup of the developers who contribute to the application?
That last question is a significant indicator for me. Suppose the product I am evaluating lets anyone contribute code changes without having a dedicated team that reviews and audits the code before merging the changes into the main code repository. In that case, I will steer clear of that application.
Ok, but really, is open-source safe?
From my perspective, I say yes-ish.
Not every tool is appropriate to keep in your developer toolbox. Use good judgment and add a little risk-aversion, and you will save yourself a lot of headaches.
If you are careful, do your research, know the source it is coming from, then open-source products can be a valuable asset to any developer.
About the author
Assistant Director, Business & Tech Services
(765) 494-6576, email@example.com