The fall of Silicon Valley Bank is a financial story, but it’s a strategic one as well. Enterprise development organizations that depend on open source or even a single small company’s code would be wise to consider that any disruption can have non-obvious effects.
Why is EkaLore so concerned over potential disruptions to open source? It is because EkaLore, in particular, has been following the massive next-generation software projects undertaken by Tesla, VW, Mercedes, and other vehicle manufacturers dependent on open source for their futures. The failure of SVB and the potential disruption in the development community is an underappreciated enterprise vulnerability.
This vulnerability exists well beyond the vehicle industry. Markets as diverse as instrumentation, biopharma, materials sciences, fintech, and web retail depend on a vibrant open source ecosystem. The general condition of open source economics compels enterprises to continue to depend on open source. The costs of that open source dependency are related to risk tolerance.
In some industries, the risk tolerance in core competency operations is low. Commercial software and vendor proprietary solutions are widely used, and there are masses of people who understand and can work with/work around those solutions. Good examples of extensively supported applications include SAS/SPSS in medical/pharma/bio, ERP packages in manufacturing, logistics software in transportation, web software for human resources, and more. In applications requiring certification, continued support, and PCAOB rules, the need for stable and supported software is explicitly a regulatory and legal requirement. For critical applications in avionics, implantable devices, instrumentation operation, and telecommunications, there are no substitutes for proprietary software as the ‘industry standard.’ Open-source software is now being used in environments where the severity of a single problem makes it risk intolerable.
In manufactured products with embedded functionality, there are dependencies for open source that are not necessarily visible, though present everywhere. Open source drives the home router/networking box, the embedded operating system in Amazon, Google, or TV gadgets bought for the home or work. Android phones are open source. There isn’t a question of whether or not open source is present – the question for enterprises is whether this affects their products and reputations.
These hidden dependencies are a known consequence of these trends in software development, operations, and IT Management. Enterprise IT shops must not become vulnerable while taking advantage of this ecosystem with many benefits. First key fact: almost all enterprises are vulnerable to code module failures in open source/community-supported software. The level of vulnerability differs from enterprise to enterprise and how risks are managed. The risks from a large-scale failure like SVB were previously not looked at by most enterprises.
The label ‘open source’ looks at vulnerabilities in a legal category of software. The same vulnerabilities also occur in commercial software dependent on open source software. The open source software includes developer/computer programming languages: R, Perl, Python, Java, JavaScript, HTML5, Rust, Go, and C/C++; and their respective developer toolchains. The open-source operating systems are similarly vulnerable: Linux (and variants like Automotive Linux), SELinux (and embedded variants), *BSD, Android, and hypervisors. Most critical are the code module libraries always in a high state of updating/fixing (Linux libraries, ISC Bind/DHCP/KEA, LibC/GTK/Perl-5/Python), and high dependency subsystems (OpenSSH, OpenSSL, OpenVPN, MySQL, EnterpriseDB, FRR).
Our next post will look at the historical background behind our reasoning as well as recommendations for how to deal with the development risk.
You can read other posts on this topic area at www.ekalore.com/ars
Comments