Understanding what are, and aren't your software suppliers
There’s no debate that Software Supply Chain Security is a topic that is front-and-center in the cybersecurity industry dialogue.
Coming on the heels of events such as SolarWinds, Log4j, the Cyber Executive Order (EO) and a slew of guidance and activities from both governmental sources such as NIST, OMB, CISA, NTIA and others along with industry leadership and publications from organizations such as Google, OpenSSF, The Linux Foundation and OWASP, Software Supply Chain is easily one of the most discussed topics in cyber currently.
Organizations are now looking to use guidance and best-practices published from organizations such as the Cloud Native Computing Foundation (CNCF), Cloud Security Alliance (CSA), National Security Agency (NSA) and NIST, just to name a few.
Thanks for reading Resilient Cyber! Subscribe for free to receive new posts and support my work.
Much of this discussion revolves around understanding your software supply chain and your suppliers and the risk associated with the software and services you consume from them.
There’s just one catch, most modern applications are overwhelmingly made up of Free and Open Source Software (FOSS), often governed under associated licensing schemes and offered to the public for use with no formal service level agreements (SLA)’s, contractual requirements or obligations levied upon the actual creators and maintainers of the software.
This reality is captured perfectly by Thomas Depierre in his article on softwaremaxims.com titled “I am not a supplier”, which was published in December 2022.
Thomas points out the tremendous growth of FOSS use over the past decade and the lenient licensing associated with it that has led to massive reuse of code and libraries leading to a complex ecosystem of dependencies, either direct or transitively, embedded in nearly all modern software and even environments such as Critical Infrastructure, as captured in this report.
Much of the conversation about software supply chain security has tried to draw on parallels from manufacturing, such as the focus on Software Bill of Materials (SBOM), pulling from the concept of a BOM in manufacturing and more broadly, understanding suppliers of materials, parts, services, and equipment.
There’s just one major problem with this mental model when applying it to the software supply chain. The majority of your software and associated components aren’t coming from suppliers. You have no contractual relationship with them and they are under no formal obligation to respond to any of your requests or demands, such as providing an SBOM or remediating a vulnerability or defect under a specific timeline.
In manufacturing, you aren’t going along just picking up things that are free and integrating them into your core products and services, and instead are using a formal supply chain of actual suppliers, raw materials, suppliers of raw materials and actual formal agreements with these entities around expectations and the exchange of goods and services and their support.
This isn’t the case with FOSS maintainers.
Further complicating the issue is the reality that the majority of projects suffer from limited involvement from the perspective of maintainers. While many like to tout “Linus’ Law”, which states that “given enough eyeballs, all bugs are shallow”, this theory doesn’t hold up in the broader FOSS ecosystem.
Sure, maybe major initiatives such as the Linux Kernel and Kubernetes have a massive pool of talented and passionate maintainers and contributors, but that isn’t the reality for the majority of the FOSS ecosystem.
There are millions of FOSS projects and often they are maintained by a small group or even single individual, all participating on a voluntary basis. For example, this study found that almost 25% of FOSS projects have a single contributor. Going further, almost 95% of projects have less than 10 developers contributing the bulk of the codecase, based on studies such as this one by Synopsys.
It’s worth noting that of course proprietary software vendors and organizations have resource constraints as well, limiting the number of developers and contributuins they may be able to have in software, but at least in those cases the software consumers have some formal recourse and agreements such as SLA’s and contracts.
You generally have none of those with a FOSS maintainer.
What this means is that for the majority of your software component makeup, you don’t have suppliers, you have an ecosystem of free and open source software maintained by volunteers, of whom which you are in no position to make demands of.
As Thomas points out in his article, most FOSS software and libraries contain languages like the one below.
This is why you often hear the phrase FOSS is like a “free puppy” because it is free in the sense that you can have it, but you ultimately own the care, feeding, upkeep, and safety of said puppy. The same applies to FOSS you’re using within your enterprise, applications and environments.
This means that you, the software consumer, must be fully prepared to potentially fork and take responsibility for the code if the maintainer is unresponsive or isn’t taking actions that align with your organizations risk tolerance. You may also need to take other steps, such as “Virtual Patching” which we have discussed in this post about the OWASP Virtual Patching Cheatsheet titled “What do you mean there isn’t a patch”?
While there is a lot that can be said and discussed on this topic, one thing is clear.
FOSS is a core engine that powers much of our modern digital society, and the majority of it is for use “as-is”, with no warranties, promises, or contractual assurances.
Researcher Chinmayi Sharma captures this incredibly well in her article titled “Open-Source Security: How Digital Infrastructure Is Built on a House of Cards” on Lawfare Blog.
Chimayi points out that 97% of software contains some amount of FOSS and FOSS code exists in 100% of systems related to computer hardware, semiconductors, cyber, energy IoT and the list goes on. Chinmayi cites studies showing that 81% of OSS code contains at least one vulnerability and an average of 5 high or critical vulnerabilities that remain unpatched. This problem is even further exacerbated by the complex tail of transitive dependencies, which are dependencies your application may not use directly, but your direct dependencies use.
Studies from sources such as Sonatype and Endor Labs in their “State of Dependency Management” report have found that 6/7 transitive dependencies contain vulnerabilities. Many organizations struggle to understand their direct dependencies in large complex enterprises, let alone transitive dependencies. This report found that 95% of vulnerable dependencies are transitive.
Much like software vendors extensively rely on OSS, so do enterprises for internal development and digital transformation initiatives. It is pervasive across nearly all organizations and our most critical infrastructure.
What does this mean?
This means while the focus, guidance and discussions we are seeing around software supply chain security are excellent, software consumers need to be sure when they start trying to bolster their software supply chain, they understand what their suppliers are, and potentially more importantly, what portion of their digital footprint doesn’t come from a “supplier”.
As Thomas explains in the “I am not a supplier” blog, there is no relationship, consumers using these FOSS components in their products makes it THEIR responsibility, not the maintainer or creators. Consumers arbitrary demands and expectations are meaningless to FOSS maintainers.
That said, if you want them to become an actual “supplier”, you may want to start considering compensating them. If not, you better be prepared to step in when, not if, the next software supply chain attack occurs.