Software Supply Chain Explained

Educational Foundations | Reading time: 14 minutes

Is this article helpful?

As a customer or potential customer of Sonatype’s Nexus platform, you may have heard references to software supply chain automation. Perhaps you know exactly what that means—maybe it’s even the reason you’ve decided to add one or more Nexus products to your own software supply chain.

But others may wonder, “What does that mean, exactly?” In this article, we’ll tackle that question, including the the following topics:

  • What supply chain management means in the context of a traditional, manufacturing-centric organization
  • How supply chain management principles and processes can be applied to software development organizations
  • How different roles in the Software Development Lifecycle (SDLC) fit into software supply chain management, and what their responsibilities are
  • How the Nexus platform fits into software supply chain management processes

What is Supply Chain Management?

According to Wikipedia, supply chain management is “…the management of the flow of goods and services, involves the movement and storage of raw materials, of work-in-process inventory, and of finished goods from point of origin to point of consumption.”

For easier memorability, let’s list out those key elements of the definition again. Supply chain management is concerned with the:

  • Flow of goods and services
  • Movement and storage of raw materials
  • Work-in-process inventory
  • Finished goods from point of origin to point of consumption

You probably noticed the keywords “flow” and “movement” in the definition—supply chain management is, at its core, concerned with how a product moves from its earliest planning stages—from procuring the necessary raw materials, controlling inventory, managing risk, gaining efficiencies during production, and releasing to the customer.

You might also think, “But what do raw materials, inventory, and production have to do with software development?”

If your role is involved in any phase of the Software Development Lifecycle (SDLC), you’ve probably noticed the shift in recent years in how software is developed. Gone are the days of individual developers writing bespoke code from scratch in isolation. The rise of open source software, Agile development methods, and DevOps concepts and practices have resulted in a much more collaborative, accelerated, and modular way of creating software.

If you look closely, you can see the parallels between how traditional manufactured goods and modern software are produced.

In the following sections, we’ll break down supply chain management principles and processes and discuss how they apply to software development.

Supply Chain Management Principles: How Do They Translate to Modern Software Development?

W. Edwards Deming, an engineer, professor of statistics, and management consultant who is often credited with the teachings that helped launch the Total Quality Management (TQM) movement in the United States, developed 14 key principles that he believed would help businesses increase product quality while simultaneously reducing costs, many of them later becoming foundational aspects of supply chain management.

He advocated for viewing manufacturing as one complete system, rather than disparate elements, and was an early promoter of concepts that are now also foundational to the DevOps movement: things like breaking down barriers between departments, seeking to continuously improve, driving out managing through fear, building quality in, and many more.

In Forrester’s Use DevOps and Supply Chain Principles to Automate Governance report, Sonatype CTO, Brian Fox, discusses some of the key Deming principles that apply for organizations as they shift toward thinking of their SDLCs as software supply chains:

“[W. Edwards Deming] taught us that a supply chain process could maximize speed and quality by doing three essential things: [1] maintain fewer and better relationships with suppliers, [2] procure only the best components from those suppliers, and [3] track the precise location of every component throughout the supply chain.”

We’ll discuss more about how these principles are carried out in supply chain management as we move through the following sections.

Supply Chain Management Processes: How Do They Apply to Modern Software Development?

Procurement = Architecture & Sourcing

In the procurement—or sourcing—stage of supply chain management, raw materials and components needed to manufacture the end product are purchased and obtained. In traditional supply chain management, many strategic factors go into the sourcing process, while procurement deals more closely with the tactical operations to acquire the materials/components.

Sourcing/procurement of open source components to develop a software application is on the rise. In fact, according to Sonatype’s State of the Software Supply Chain report, weekly downloads of JavaScript OSS components from the Node Package Manager (npm) increased 185% in 2018 alone.

JavaScript Package Downloads

Strategic sourcing in software development includes being deliberate about your component selection—ecosystem package managers for a particular language (e.g., The Central Repository for Java, npm for JavaScript as shown above, etc.) are increasingly relied on as “trusted” suppliers for these OSS components.

Production = Development

The production stage in a traditional supply chain is where all of the sourced raw materials and components come together to be assembled. Think of a factory assembly line, à la Ford Motor Company.

If you think of software development in factory terms, one of your first thoughts might be that it isn’t observable in the way that a physical manufacturing factory floor would be. But if we return to those basic underlying keywords of the movement and flow of goods to build a system, you can start to see that modern software development operates similarly in that developers “assemble” applications, pulling in the sourced OSS components with the necessary functionality (parts) into their software (finished goods).

Distribution = DevOps

When it comes to distribution in a traditional supply chain, the goal is to “ensure that goods are flowing quickly and safely toward the point of demand.”

This acceleration of “goods” to the customer is at the heart of the DevOps movement within the software industry. If you’ll recall the definition of DevOps that we arrived at in our What is DevOps? guide, the principles we discussed all “work toward a common goal of shortening software delivery cycles and improving the stability of deployments.”

DevOps-minded teams and engineers are constantly thinking about this flow, which involves not only the right tooling to move the development and distribution process forward (e.g., CI/CD), but also essentials such as a culture of trust to communicate issues early and often, helping avoid major roadblocks in releasing the “finished goods” to customers down the line.

Customer Interface = Customer Success

Traditionally, the customer interface stage of supply chain management is concerned with “planning customer interactions, satisfying their needs, and fulfilling orders perfectly.”

For today’s SaaS-based companies, this customer interface stage is called Customer Success, which is increasingly important in assuring customers achieve their intended business outcomes with their purchase, in turn making them more likely to renew.

How Do SDLC Roles Fit into the Software Supply Chain?

Now that we better understand the high-level processes involved in supply chain management, and how they translate into modern software development practices to form a trusted software supply chain, let’s take a look at how SDLC roles fit into software supply chain management.

Product Manager

A product manager is responsible for establishing the product vision and strategy to meet customer needs. Product managers are involved in the discovery and planning stages (product vision, user requirements/stories, etc.), defining product features at a high-level, performing competitive analysis, and possibly even communicating directly with customers (or via proxy through Customer Success) to better understand feature requests and customer use cases.

Software Architect/Software Developer

Once a product manager has defined user stories to guide the development team, the work of software architects and developers begins. While investigating how to achieve the necessary functionality in the software they’re developing, architects/developers should have a vested interest in the quality, maintainability, and general health of OSS projects publishing the components they’re choosing.

Depending on whether architectural guidelines for OSS selection have already been established, software developers may be more or less involved in the initial sourcing process.

However, for “procurement” of OSS components, software developers are responsible for declaring the necessary OSS dependencies in their code (often with the assistance of a dependency manager) that provide necessary functionality for the software they’re building.

“Production” itself takes place within the Integrated Development Environment (IDE) for a developer, along with Source Control Management (SCM) and Continuous Integration (CI) tooling.

Finally, much of the quality control of software is automated these days as part of agile development, so a developer would likely oversee the testing portion of the SDLC as well, unlike a traditional supply chain where quality control, or validation, is performed by a separate group.

DevOps Engineer

DevOps Engineers come into play along the entire SDLC, but especially during the “production” (i.e., development) stage, operating as supply chain managers would: providing production support. DevOps engineers are responsible for a lot of moving pieces as well as the underlying infrastructure that enables the product to function after it is “distributed” (i.e., deployed).

Speaking of “distribution”, this is where a DevOps engineer’s primary functions really come into play. Smooth software deployments mean that the moving parts are all functioning properly and released in a timely, stable way to the customer.

Customer Success Engineer/Manager

Customer Success Engineers/Managers, as we discussed earlier, are increasingly important roles in an organization’s SDLC. Just as the Customer Interface function within traditional supply chain management helps to “fulfill orders perfectly,” Customer Success Managers in modern software development help ensure customers are achieving value (i.e., their desired business outcomes) from their product purchase.

According to the book Customer Success, organizations that do this best—reduce time to value for their customers— have better customer retention.

“In the world of SaaS or subscriptions, delivering that value quickly is key to retention and expansion. Customers don’t renew or stay with you or buy more unless or until you deliver value to them.”

How Does the Nexus platform help automate Software Supply Chain Management?

We now have a pretty good grasp of the principles and high-level processes involved in supply chain management, how they translate to modern software development practices to form a software supply chain, and how SDLC roles fit in.

Next, let’s talk about how Sonatype’s Nexus platform helps automate some of the key elements of software supply chain management. The Nexus platform includes our Nexus Repository Manager binary repository manager solution, as well as Nexus IQ Server, the policy engine behind our Lifecycle, Firewall, and Auditor solutions.

Software Supply Chain Explained

Nexus Repository Manager: A Trusted Warehouse for Parts

In Out of the Wild: A Beginner’s Guide to Package and Dependency Management, we discussed how using a binary repository manager can help further your DevOps goals.

Organizations operating in a software supply chain automation frame of mind are already making use of this often under-valued DevOps tool. Development starts with the selection of suitable components for your projects based on comprehensive information about the components and their characteristics. Using a dedicated toolset devoted to centralizing the storage of your binaries allows for better management of not only downloaded OSS components to be used by developers during “production,” but also for developers to generate their build artifacts used by DevOps engineering for “distribution.”

Nexus Repository Manager Pro also includes features such as the display of security vulnerabilities and license analysis results within Repository Health Check for a proxy repository.

Having a centralized repository model to manage the software build assets is typically the first step in achieving a level of control within your SDLC. Once you start adopting a repository manager as this central point of storage and exchange, you’ll want to expand its use in your efforts to automate and manage the software supply chain throughout your entire software development lifecycle. That’s where the next piece of the Nexus platform—Nexus IQ Server—comes in.

Nexus IQ Server: Policy-Driven, Precise Intelligence

Nexus IQ Server is a policy engine powered by precise intelligence on open source components. Nexus IQ is the “brain” behind three solutions—Firewall, Lifecycle, and Auditor— which improve component usage in your software supply chain, allowing you to automate your processes to achieve accelerated speed to delivery while also increasing product quality.

Nexus Firewall: Protecting Your Trusted Warehouse

Unfortunately, even trusted suppliers can sometimes provide “faulty” parts. And bad actors are increasingly “poisoning the well.” That’s where Nexus Firewall comes in. Nexus Firewall lives “on top” of your Nexus Repository Manager, working in conjunction with the proxy repositories that are set up within your repository manager to download from package repositories like Maven Central or npm. Powered by the policy engine of Nexus IQ Server, Firewall can block any components from entering your repository manager based on the security, legal, and architectural policies you’ve defined. It provides an added layer of security and control, helping ensure that your repository manager remains a trusted warehouse for sourcing parts.

Nexus Lifecycle: Software Bill of Materials and Actionable Intelligence

Nexus Lifecycle is Sonatype’s Software Composition Analysis (SCA) tool, which allows you to scan an application and receive an Application Composition Report, which provides an inventory—or Software Bill of Materials—of the OSS components used within that application. These SBOMs include any security, legal, or quality risks associated with each component with precise, contextual information, across multiple points of integration: IDEs, source control, or CI/CD tooling—basically wherever development teams prefer to view the information necessary for their everyday work.

We mentioned earlier that inventory management is an essential part of traditional supply chain processes, with a Bill of Materials for tracking purposes, especially when defects in parts are found.

Think of a recall for a manufactured product, such as the Takata airbags used by several different automotive manufacturers. In a traditional supply chain, without a detailed Bill of Materials, the manufacturer wouldn’t be able to identify which vehicles were built with which airbags, and the recall capability wouldn’t exist.

Yet, we often build software in this exact way, without insight into which OSS components are used in which applications.

That’s why shifting our thinking to software development in the context of the larger software supply chain is so important, as open source usage and breaches increase. As Brian Fox explains in his Forbes article, Open Source Developers and Infrastructure are the New Frontline of Security:

“If you are a consumer of open source components, think of this as a supply chain problem:

  • Understand where your parts are coming from. Does the vendor produce quality parts? Are they counterfeit?
  • Reduce the scope of redundant versions of parts you include in your applications. This reduces the surface area both of attacks and of what you need to manage.
  • Build a bill of materials of where all these parts go into your applications and continuously monitor for new disclosures. This is the only way you have a chance of immediately assessing your exposure and targeting your remediation when, not if, the next disclosure occurs.”

Nexus Auditor: Continuous Monitoring of Production Applications

Once a software application is deployed; that is, it becomes a production application, you’ll want to stay on top of any risks that might pop up after-the-fact to minimize the risk to your customers. “Continuously monitoring for new disclosures” as Fox states above is an essential part of software supply chain automation, and that is where Nexus Auditor comes into play. You can be immediately notified if a new vulnerability is found in a component used in your production application.

Nexus Integrations: Software Supply Chain Automation Realized

Finally, Nexus Integrations are what make the Nexus platform a seamless software supply chain automation tool. Using your favorite developer and DevOps tooling, Nexus integrations allow you to build software supply chain automation into your daily development efforts, your continuous integration builds, and your release processes. Our integrations let you work in your preferred toolset while still having access to actionable intelligence to make informed decisions about your components.

Why Does Software Supply Chain Automation Matter?

According to State of the Software Supply Chain report, a study of 85,000 applications revealed that managed software supply chains are safer, with a 55% reduction in the use of vulnerable open-source components in companies that managed their open source software supply chains.

Proportion of Vulnerable Components in Unmanaged vs. Managed Supply Chains

As Hines discussed in his book Supply Chain Strategies: Demand Driven and Customer Focused, “supply chain strategies require a total systems view of the links in the chain that work together efficiently to create customer satisfaction at the end point of delivery to the consumer.”

When it comes to the software applications that your organization builds, customer satisfaction is predicated on being able to trust that the software they’re using won’t result in their information being breached. Building security into your software through a managed software supply chain approach is one of the most customer-focused things development teams can do to harden the SDLC and make it trustworthy.

Finally, some of the key benefits of supply chain management are in managing risk and gaining efficiencies. The same benefits can and should be carried over to your own software development processes by focusing on what W. Edwards Deming taught us:

  • Never pass known defects downstream.
  • Continuously track the location of every part.
  • Source parts from fewer and better suppliers.
  • Use only the highest quality parts.

Sources:

Bill of Materials Wikipedia entry

Customer Success: How Innovative Companies Are Reducing Churn and Growing Recurring Revenue by Nick Mehta, Dan Steinman, and Lincoln Murphy

Open Source Developers and Infrastructure are the New Frontline of Security by Brian Fox

Out of the Wild: A Beginner’s Guide to Package and Dependency Management

State of the Software Supply Chain report

Supply Chain Management Concepts

Supply Chain Strategies: Demand Driven and Customer Focused by Tony Hines

Supply Chain Management Wikipedia entry

Total Quality Management Wikipedia entry

Use DevOps and Supply Chain Principles to Automate Governance Forrester report

W. Edwards Deming Wikipedia entry

What is DevOps?

Why You Need a Software Bill of Materials Now More Than Ever by Katie McCaskey