Since the dawn of the proprietary and open source software divergence there has been the on-going debate on the security implications of these two distinct approaches to software development.

Proponents for proprietary software have championed that since their code is not publicly shared that it is harder for bad actors to exploit these systems and applications. However, open source advocates have argued that since their code is open and editable by all that it promotes more scrutiny on the code itself and thereby increases its overall security posture.

In the early 2000’s there was much research and several publications on this topic. Much of the research supported the argument that open source was more secure and the debates subsided. As a result, some historically strict proprietary organizations shifted their software development practices to a more open source model.

In recent years the debate has begun to arise once again. However, nothing has changed to the software development models for either of these approaches. The conversation should not simply reignite the same question but rather focus on what has actually changed - the method of attacks.

Therefore, it is important to distinguish that open source software itself is not less secure than proprietary software but rather that supply chain attacks have exploited open source practices. The focus should be on securing the software supply chain, not that open source software is insecure.

Security of Open Source Software

In the 1990's and early 2000's there was a debate and open question on the security posture of open source software. Proprietary software organizations went on the attack against open source applications stating that they were less secure. Why would these organizations make these claims? I personally can not speak to their motives but I can wager that it was most likely because open source was a threat to their bottom line.

Open source shares its source code to all. It makes the code free, accessible, sellable, and editable by anyone. Who would want to pay for software if they could access something of a similar quality for free? The claim that open source was less secure than proprietary software was a highly targeted argument directed right to the audience of corporate America.

Corporations and Governments could not afford to have insecure software. If open source software was less secure than proprietary software - this would give corporations and Governments the reason to buy proprietary software - even if a free and comparable alternative existed.

Open source advocates worked to prove that open source was not less secure. Data was collected, papers were written, presentations at conferences were presented [1][2][3]. Eventually, the debate subsided as more and more empirical evidence that open source was not less secure than proprietary software amassed. Many proprietary software companies ended up embracing the open source model [4][5][6]. The open question appeared to be answered and the debate settled.

Increases in Supply Chain Attacks

In December of 2020, supply chain attacks were brought to the forefront with the SolarWinds attack [7] when malware was used to insert a backdoor into software during the build process by replacing one of the source code files via a highly utilized network performance monitoring tool. This action was executed at a key point in the build process and impacted organizations of all sizes across the globe. Since then, several other notable supply chain attacks have taken place such as JFrog, Okta, and Log4J to name a few. Attacks such as these are costing organizations millions, and sometimes billions [8], of dollars.

Of particular concern is that these attacks have only provided evidence of their ability to greatly and vastly impact organizations across the globe quite efficiently. As a result, the increase of these attacks is astonishing. According to Statista [9] the number of supply chain attacks increased 58.8% from 2022 to 2023; and have increased a staggering 1,090% from 2019 to 2023.

Even as the industry overall is diligently trying to mitigate these attacks with educational campaigns, publishing security frameworks, implementing regulatory changes, and promoting the practice of sound security principles - these attacks continue.

Of course it is much easier for some to reignite the argument that open source software is to blame; however, this is a red herring. The use of open source software itself is not insecure. An insecure software build process is the real culprit. If supply chain attacks are used as a premise that proprietary software is more secure than open source then it would be negligent to not clarify that proprietary software is often composed of hundreds, if not thousands, of open source packages itself. Similarly, propriety software also utilizes a supply chain to build and release it's products - at which point all software is vulnerable.

Securing The Supply Chain

Now that we have clarified that all software is vulnerable and that the everyone's software supply chain must be secured, there are some simple actionable steps that you can take that will increase the security of your software supply chain. In order for this article to be beneficial and relevant for years to come I will point the reader (that's you) to some helpful references, frameworks, and standards that will evolve as the software ecosystem changes. Following these standards and frameworks will allow you to take actionable steps to secure your supply chain over time.

A great first step is to delve into SLSA (pronounced salsa), an open source community for Supply chain Levels for Software Artifacts [10]. It outlines levels of supply chain security with actionable steps to take at each level. Start at Level 1 and grow as your organization grows! The documentation is extremely helpful - and hey - who doesn't like salsa? And if you like salsa, how about trying out some Guac [11]? This project is extremely exciting and gives you actionable information and insight into your supply chain by helping you interpret whats in your software.

Some other very helpful references would be to head over to The National Institute of Standards and Technology and read [12][13][14]; The Cloud Native Computing Foundation (CNCF) also has a great read entitled “Software Supply Chain Best Practices” [15].

At the core of these frameworks is to know, document, and ask for the who, what, when, where, and how of your software build process. Know which libraries and packages are in your software, what systems are being used to build your software, who is doing what to your software during the build process, who has access to modify code during your build process, are they authorized to make those changes, what vulnerabilities currently exist in your software and what is their severity, and be able to verify or validate all actions taken on the source code from the developers workstation (or git repo) to the product release end-point and/or customer. Only by knowing this information will you be able to adequately and quickly respond to the inevitable supply chain attack your organization will experience.

Most importantly, I would urge the reader (that's you again) that implementing any of the suggested activities is better than doing nothing at all. Please don't view security as an all-or-nothing activity. Address security like you would a healthy lifestyle, yes it's ideal to do all-the-things - but in reality any healthy behavior will indeed benefit your body in one way or another.

Conclusion

Open source software is not inherently insecure but is rather being exploited in a different way. Additionally, no software (proprietary or open source) is immune from supply chain attacks. It is crucial that we continue to focus our efforts on securing the software supply chain and not reigniting a debate to a previously answered question.

References:

1. Payne, C. (2002). On the security of open source software. Information systems journal, 12(1), 61-78.

2. Erturk, E. (2012, June). A case study in open source software security and privacy: Android adware. In World Congress on Internet Security (WorldCIS-2012) (pp. 189-191). IEEE.

3. Boulanger, A. (2005). Open-source versus proprietary software: Is one more reliable and secure than the other?. IBM Systems Journal, 44(2), 239-248.

4. Open source. Microsoft Legal. (n.d.). https://www.microsoft.com/en-us/legal/intellectualproperty/open-source

5. Google open source. Google Open Source. (n.d.). https://opensource.google/

6. Open source at IBM. IBM Developer. (n.d.). https://www.ibm.com/opensource/

7. Team, C. I. (2021, July 13). Sunspot malware: A technical analysis: CrowdStrike. crowdstrike.com. https://www.crowdstrike.com/blog/sunspot-malware-technical-analysis/

8. Page, C. (2023, August 25). Moveit, the biggest hack of the year, by the numbers. TechCrunch. https://techcrunch.com/2023/08/25/moveit-mass-hack-by-the-numbers/?guccounter=1&guce_referrer=aHR0cHM6Ly93d3cuZ29vZ2xlLmNvbS8&guce_referrer_sig=AQAAALAzT_UDiJfBBeJAxwQmnL44EINEbtSE2JPOaZKyGmbAG9UDx3cWekJsImFydQkUFh9xUgeXGV-knuFWKcPiYePf9jT8Z1QRrN38lcEWTfE1-HUMokDREbVtE8fYX8l6M6O-atP9Pm4fq5RSRRNlcps7zyCW5GUdNdo2QVMvehSN

9. Ani Petrosyan, & 26, M. (2024, March 26). Annual number of Supply Chain Cyber attacks U.S. 2023. Statista. https://www.statista.com/statistics/1367208/us-annual-number-of-entities-impacted-supply-chain-attacks/#:~:text=U.S.%20number%20of%20entities%20impacted%20in%20supply%20chain%20cyber%20attacks%202017%2D2023&text=In%202023%2C%20supply%20chain%20cyber,percent%20year%2Dover%2Dyear.

10. Supply-chain levels for software artifacts. SLSA. (n.d.). https://slsa.dev/

11. Guac. guac. (n.d.). https://guac.sh/

12. Computer Security Division, I. T. L. (n.d.). Cybersecurity Supply Chain Risk Management: CSRC. CSRC. https://csrc.nist.gov/projects/cyber-supply-chain-risk-management

13. Cloud Native Computing Foundation (CNCF) at Main · CNCF/tag-security. (n.d.-a). https://github.com/cncf/tag-security/blob/main/supply-chain-security/supply-chain-security-paper/CNCF_SSCP_v1.pdf

14. Souppaya, M., Scarfone, K., & Dodson, D. (2022). Secure software development framework (ssdf) version 1.1 NIST Special Publication, 800, 218. https://csrc.nist.gov/pubs/sp/800/218/final

15. Order, E. (2021). 14028, Improving the Nation’s Cybersecurity. https://www.nist.gov/itl/executive-order-improving-nations-cybersecurity/software-supply-chain-security ; https://www.whitehouse.gov/briefing-room/presidential-actions/2021/05/12/executive-order-on-improving-the-nations-cybersecurity/

16. Software bill of materials. SOFTWARE BILL OF MATERIALS | National Telecommunications and Information Administration. (n.d.). https://www.ntia.gov/page/software-bill-materials

17. Owasp Mobile top 10. OWASP Mobile Top 10 | OWASP Foundation. (n.d.). https://owasp.org/www-project-mobile-top-10/