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 include:
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. It is now seen as a core competency and strategic imperative that defines the entire enterprise. It’s also why organizations around the world are embracing a new approach that streamlines how you manage the software your applications depend upon.
This approach addresses how software development processes are connected, known as the “software supply chain.”
The faster companies bring value to market, the more the market rewards them. Effective software supply chain management means tearing 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 up engineering process 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. It also exposes software to a global community of “co-developers” to consider 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 discuss the profound growth of open source software further in Part 2 of this series.
What’s important today is how development without open source software components is a rarity. And what’s increasingly part of the conversation is how to address the process of developing software using components 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:
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. And a crucial piece in understanding that landscape is how it’s made up of component parts. In fact, almost no modern software project starts from the ground up. They are instead built atop existing software.
It is the way these components are developed, shared, and put into use that is our focus. It is an ongoing and connected process known as the “software supply chain”.
If you hadn’t heard the phrase 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 2020 SolarWinds’ attack that the concept started gaining traction in the mainstream. This represented a sea change in conversations around security. Where before concerns had always centered around a previously undiscovered or “zero-day” software vulnerability, the SolarWinds issue was caused by tainted third-party code.
Following multiple, high-profile breaches caused by issues in component software development, in May 2021, President Biden signed the Cybersecurity Executive Order. This document included detailed requirements around the protection and security of the software supply chain.
Then in August, the White House Office of Management and Budget released a memo Protecting Critical Software Through Enhanced Security Measures. The document further underlined the danger to “the public sector, the private sector, and, ultimately, the American people’s security and privacy.”
...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. The term is almost always followed by “attack” or “security.” We agree that securing the software supply chain is fundamental, but it’s only one part of 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, and technical debt, as well as 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 all the 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 re-using code and writing it from scratch?
Many application teams will use the same or similar components as they build out that software 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)
The lack of understanding mentioned above is 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 management is difficult, 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.