Key Concepts

Software Supply Chain Version Management

Versioning the Supply Chain For Change Tracking and Trends

What is Software Supply Chain Versioning?

Software supply chain ‘versioning’ refers to the process of tracking all of the attributes of each deployed component delivered to end users, including key-value pairs, SBOMs, open-source packages, CVEs, licenses, swagger details, consuming applications, and deployment meta data. The ability to track and manage versions all the components that make up the software supply chain is critical for tracking changes and building historical data models for future threat analysis.

The Supply Chain Changes Daily

Your Software Supply Chain changes every day and, in some cases, every hour. For this reason, software supply chain version management is essential. IT teams have become accustomed to the concepts of versioning source code and tracking changes over time with the ability to roll back to a previous state quickly. Versioning the entire software supply chain provides similar insights and benefits.

Software supply chain version management tracks every software component consumed in the supply chain and captures the component configuration, security, and DevOps data for each new version introduced. Software supply chain version management is becoming increasingly important to support decoupled, cloud-native development, where thousands of objects are continuously pushed into the software supply chain.

Monolithic Vs. Cloud-Native Configuration Tracking

In the past, IT teams have relied on a monolithic ‘build’ approach where all source code and libraries are compiled/linked and released simultaneously to end users. The build process ‘statically linked’ the binaries and created a release candidate ‘version.’ The monolithic build tracked the changes in the binaries we sent to production.  Tracking the versions of the libraries was done by the build with the help of a version repository such as Git.

With decoupled applications, independently deployed functions are delivered all day long.  No static linking is required as communication between components is done at runtime via APIs. While solving many problems, this approach makes tracking application versions difficult. Changing any of the software supply chain components will create many new application versions.  One of the most common questions is, “How do I know if different environments are using the same version of a single component?”  Component version drift across the supply chain can be difficult to track. 

Software Supply Chain Version Management Addresses Component Drift

The software supply chain is made up of component versions. Each component version has its unique configuration data, including where the component has been deployed. By versioning the changes in the software supply chain, IT teams can easily track where each version is installed across hundreds of clusters and environments. In the example below, all three websites, the candy store, clothing store, and toy store, use a set of common components, including the shipping service. Notice that ‘drift’ has occurred at the clothing store, which continues to be one version behind.

microservice versioning for drift


Most DevOps engineers will simultaneously deploy a new component to all locations to avoid drift. This is not ideal as it stands in the way of Blue/Green, canary, or rolling deployments where updates are pushed out more methodically to avoid potential errors. What is needed is a way to track the component version along with where it is running to support these deployment models. 

In addition, in some organizations, not all teams may want to adopt a new version of a common component – at least not at first. There may be a good reason the clothing store website SRE chooses to stay a version behind.

Finally, development, test, and production teams need to understand which versions of the components are running in each environment. This information gives them insights into where a vulnerability may exist or why an anomaly exists. Versioning components go well beyond registering them to an image repository. The more data that can be included in a software supply chain version management strategy, the better.

Best Practices for Component Versioning

How should components be versioned to improve their use and success in decoupled applications? It is important to remember that components are deployed independently and frequently. Second, a component is more than just a container image. It has many attributes that need to be versioned and tracked. DeployHub uses the following best practices when defining a component version:

  • Best Practice #1: A component’s attributes go beyond the contents of the container. Versioning the SBOM, CVE, licensing, Swagger details, Key-Value pairs, deployment logic, and endpoint configurations are all part of the component’s configuration and should also be versioned and tracked.
  • Best Practice #2: Don’t change the name of the components; only update the image value with the image tag.
  • Best Practice #3: Logically track a version number for every release. Use semantic versioning. Calendar versioning can get confusing if a service is changed multiple times in a single day.
  • Best Practice #4: Use the Git Commit SHA in the semantic versioning number. This helps connect back to the developer’s change.
  • Best Practice #5: Logically track the component’s consuming applications as part of the versioning strategy. Using this best practice will provide a clear picture of their impact.
  • Best Practice #6: Include a snapshot of the service-to-service API endpoint relationships.


DeployHub simplifies the complexities of a decoupled architecture with component versioning designed to create a federated view of the software supply chain. Features of using DeployHub for component versioning include:

  • Exposes ‘drift’ across all environments quickly
  • Identifies open-source packages the component version depends upon
  • Component Domain organization for sharing, reuse, and control
  • Component trends with historical data
  • Component version comparisons
  • Component to logical application relationships
  • Components Blast Radius

DeployHub uses the concepts of domains, environment, application, and component to provide the framework for managing services in their containers. Some of these terms have been seen before, like environment and application. However, terms like domains and components are new concepts that relate to how components are organized.

DeployHub’s Software Supply Chain Version Management

DeployHub’s open source software supply chain security platform tracks all changes and provides historical comparisons. Like source code versioning, DeployHub snapshots the configuration details of the component and logical application versions. This information is used for comparisons and tracking trends over time.

Learn More

Start Versioning Your Software Supply Chain Today

Signup for DeployHub Team to Start Tracking and Versioning Your Supply Chain Updates for Free

Signup for DeployHub Team, the free SaaS software supply chain security platform. DeployHub Team is based on the Ortelius Open Source project incubating at the Continuous Delivery Foundation.

Signup Today

Suggested Whitepaper

Every component version impacts one too many logical applications. Knowing which applications are impacted by a single update is critical when a problem occurs. Read how DeployHub’s open source software supply chain security platform exposes the component’s blast radius.

Get the Whitepaper

Component blast radius

Further Reading


Components are changing the way we develop, build, and deploy software. While solving many problems, components also create new challenges around tracking and versioning our overall software supply chain.

New methods and best practice strategies for component version management are needed to simplify the complexities of decoupled development. DeployHub is one such solution. Its software supply chain management catalog with built-in component versioning is designed to create a unified view of all components, who uses them, who owns them, and where they are running, with data aggregation creating logical application versions.