For every company in every industry, competition is as likely to come from an unknown startup as it is from long-established rivals. In the modern economy, if you’re not innovating fast enough, you’ll get run over by someone who is. Just ask broadcast and cable television companies about Netflix. Ask Hilton and Marriott about Airbnb. The fear of death can be a powerful motivator.
Some of the biggest challenges to incumbents are leadership teams resting upon their laurels, deeply embedded and convoluted development norms, increased cyber attacks on development ecosystems, and long-standing silos erected by software development, application security, and IT operations teams. The entrenched cultural norms and silos fuel friction, decrease velocity, and diminish innovation.
All companies are now software companies. This stark reality, and fear of death, is why many organizations no longer view software development as a cost of doing business, but rather as a core competency and strategic imperative that defines the entire enterprise. It’s also why organizations around the world are embracing software supply chain management, which streamlines how you manage the software your applications depend upon.
The faster companies bring value to market, the more the market rewards them. Software supply chain management helps tear down walls between developers and security, rips out wasteful open source practices, and rewards collaboration at scale.
Many organizations no longer view software development as a cost of doing business, but rather as a core competency.
Enter open source development practices — a key component of software supply chains and modern software innovation.
From the early days of computing, developers have understood that giving common tasks to a pre-designed system was a way to speed development and reduce production costs. This has only multiplied today with community-developed software parts, pre-built libraries, and third-party components. Open source components save companies time and money, improve quality, deliver business agility, and mitigate (some) business risk.
The concept is not new. Long before the advent of open source, Isaac Newton famously said, "I see further by standing on the shoulders of giants and I discover truth by building on previous discoveries." This idea is a primary reason why open source components are so attractive to development teams, though some in the industry were reluctant to adopt it at scale.
The same holds true for the increasing use of containerized applications. Simply stated, free and open access to pre-existing software components and containers eliminates the reinvention of wheels and exposes software to a global community of “co-developers,” to ideate on and expand upon.
Today, whatever hesitation there may have been around open source is merely a shadow. The average application is now made up of 85% open source components.
We’ll stop there for now as we’ll talk more about the growth of open source use a bit later.
Today, development without open source software components is a rarity. And what’s increasingly part of the conversation is how to address the process of component development from external sources. Companies need to recognize that software happens outside their walls and networks. What people, processes, and tools make up the software you deploy?
Let’s pause for a moment. We’re talking A LOT about open source, and we’ll continue to do so. We’ll also dig into how to use third-party parts rather than creating everything yourself, a big part of software supply chain management. But it’s not everything.
It’s crucial to also understand the other two “building blocks” of software that we’ll be talking about most that flow into your software supply chain — and what we mean by open source:
First-Party Source code - this is the original text developers write from scratch to communicate the instructions that make up software.
Open source - an umbrella term for collaborative source code development, created for public use and modification. The term is distinct from similar terms:
Source available - where the code is visible for audit purposes but not available for use or modification.
Free Software - implies a share-and-share-alike process and ethos.
InnerSource - Projects managed like open source and may use open source components, but not shared outside of a company or group. InnerSource components may power many internal tools and services. Part of a broader movement to bring wildly successful open source principles to internal development teams.
For many years now, tools and services that were handled by specialized hardware are moving to either mostly or pure software.
If your industry relied on a specific kind of chip or hardware, it’s likely shifted to generic, off-the-shelf components controlled by software. That means the software supply chain will power more and more tools and services.
If you hadn’t heard the phrase software supply chain before 2020 (or are maybe just learning about it now) you aren’t alone. At Sonatype, we’ve been researching, studying, and talking about software supply chains for almost 15 years, along with how to manage and protect them. For 7 of those years, we’ve been producing an annual report: The State of the Software Supply Chain.
Unfortunately, it wasn’t until the 2017 SolarWinds’ attack that the concept of software supply chains started gaining traction in more mainstream conversations.
Following the above-mentioned SolarWinds attack, and several other high-profile software supply chain security breaches, in May 2021, President Biden signed the Cybersecurity Executive Order with in-depth sections talking about protecting and securing the software supply chain.
Further, in 2022 the White House Office of Management and Budget made this a national concern in their memo “Protecting Critical Software Through Enhanced Security Measures”
...there is a pressing need to implement more rigorous and predictable mechanisms for ensuring that products function securely in the manner intended. The Federal Government must identify and implement practices that enhance the security of the software supply chain and protect the use of software in agencies’ operational environments.
— 2021 WHITE HOUSE OFFICE OF MANAGEMENT & BUDGET MEMO
While now saying “software supply chain,” is often met with some basic understanding, the definition varies widely depending on who you’re talking to. It is also almost always followed by “attack” or “security.” We agree that securing the software supply chain is fundamental, but it’s only one part of truly managing the software supply chain.
If we as an industry only focus on security — we’re missing possibilities for innovation, maintainability, integrity, and sustainability. Software supply chain management is complex and difficult, but it’s also about decreasing innovation tax, technical debt, and increasing employee happiness, productivity, and revenue. It’s important for developers and security teams to understand, but just as important for DevOps leads, CISOs, general IT professionals and lawyers, and many people in between.
This is a new situation that brings with it new terms and tools to try and describe it. How does it fit into the landscape of modern software development? What’s the balance between code being mostly borrowed from other sources and written from scratch? Many programs will even borrow the same or very similar components with only a small percentage of differences between them. This is indicative of the wider software industry: taking parts from different places, configuring them, and distributing or selling the result as a part of a service or a program unto itself.
The good news is that a lot of these concepts have come a long way and are improving software for everyone. But in order to explain today’s problems, you need to know what these things mean.
Software supply chain management is complex and difficult, but it’s also about decreasing innovation tax, technical debt, and increasing employee happiness, productivity, and revenue.
A problem well-defined is a problem half solved
(John Dewey, 1938)
All of these points mentioned above are why we set out to create this introductory guide to software supply chain governance. What follows is a look at where this came from, why it’s only getting more complicated, and what that means for the world beyond software. We also look at some of the tools and policies you should be employing to protect your company/development environment/software project, etc.
Before we move on, we also want to note that this will be a living document. As we’ve already said, software supply chains are complex. We know we’ve only scratched the surface on what makes up the software supply chain. And while we think it’s already the most comprehensive overview, we know we’ve missed a lot. We want it to be a truly definitive guide to software supply chain management — and that’s going to take time to get it right.
Since it might not be possible to do that alone, we’d love your help. If you see something we missed, or you’re interested in contributing content to this endeavor, please reach out to us.