Everything You Need to Know About Dependency Vendoring

Outsourced Dependency Vendoring
Dependency Vendoring is a dependency management strategy that recommends including third-party software source code directly in your product’s codebase. In practical terms, that means checking open source dependencies into your source control system rather than relying on a package manager to install the dependency on demand.

Dependency vendoring has often been called “the least worst way” of managing software dependencies, because, like every other dependency management strategy, dependency vendoring has both pros and cons:


  • Avoid Conflicts – by including a specific version of a dependency in your code you can ensure compatibility with all the other components in your codebase.
  • Avoid Breaking the Build – package managers (unless explicitly instructed not to) will import newer versions of dependencies and/or transitive dependencies as they become available, potentially breaking the build.
  • Consistency – ensures the build works reliably and consistently on every team member’s machine.
  • Faster Fixes – potentially allows you to customize, patch and/or add new functionality to the dependency in a more timely manner than the original vendor.


  • Build It Yourself – rather than simply installing prebuilt dependencies from a public repository you’ll need to build them from source code, along with all of their transitive dependencies and any native libraries from source code for each OS your development team works with. This requires both language and OS expertise your team may not have. 
  • Outdated Dependencies – once checked in to a code repository, dependencies are all too often never updated (see report) for fear of breaking the build. This can lead to buggy codebases riddled with security holes.
  • Clutter – adding all the third-party dependency source code to your repo often creates a very large source tree, and can make tasks like code review and license audits more difficult than they should be, especially if the code is poorly organized and/or documented.
  • You Own It – if your organization uses a standard set of dependencies for every project, other project teams may be coming to you to fix, update, patch or otherwise manage the dependency you checked in. 

Determining whether the pros outweigh the cons for your project(s) depends on the software development processes your organization has adopted. In some cases, dependency vendoring may introduce more work than it solves. But what if you could make dependency vendoring someone else’s problem?

Dependency Vendoring as a Service

There are actually quite a few aspects of dependency vendoring that are available “as a service” today for the simple reason that manually trying to manage all the tasks associated with dependency vendoring is a recipe for disaster. As a result, most organizations rely on automated tooling to help with tasks like:

  • Security – third party services like GitHub’s dependabot or Software Composition Analysis (SCA) tools automatically identify dependency vulnerabilities in a timely manner, and may also suggest remediation options.
  • Compliance – the same SCA tools can also be used to identify the open source licenses in your dependencies, and help ensure compliance with your organization’s licensing guidelines. 
  • Building from Source – third-party CI/CD solutions are typically used to build dependencies from source code and package them for deployment on one or more target platforms.
  • Control – making a set of pre-vetted, approved dependencies available for use by an organization’s teams (and managing them over time) is easier if they’re located in a central artifact repository.

Unfortunately, automating all these tasks means cobbling together multiple tools and processes since no existing solution automates them all out of the box. Worse, much of the automation on offer is only minimally effective. For example, it’s one thing to be notified of a vulnerability and a newer version of the dependency that resolves it, but quite another to build that new version, ensure it works with your existing environment, and redeploy/update all your existing dev, test and production instances. In practice, this kind of self-serve automation really means developers end up dedicating a large chunk of their time to continuously managing dependencies rather than coding, thereby increasing operational costs and time to market.

Full Serve vs Self Serve Dependency Vendoring

For this reason, there is an emerging class of full-service providers that can take much of the non-differentiating dependency management work off your hands so your developers can focus on delivering differentiating features and functionality instead. These vendors include:

  • Tidelift – while they also provide self-serve tooling, behind the scenes Tidelift has a large base of dependency maintainers that help subscribers manage any security, maintenance, and licensing issues that might arise when using a dependency. This removes the burden from your team and places it back where it belongs: with the maintainers of the dependency themselves.
  • ActiveState – like the rest of the market, our offerings are available via self-serve, but many of our customers actually prefer our “managed distribution” full-service offering, which includes:
    • Vetting your dependencies from our catalog of third-party dependencies to ensure security, maintainability and appropriate licensing according to your corporate guidelines. 
    • Securely building your set of required dependencies from source code, including native libraries.
    • Packaging your set of dependencies for all target operating systems, ensuring reproducible environments that contain only dependencies that work together.
    • Optionally making your built dependencies available via our artifact repository for easier management and distribution.
    • Monitoring dependencies for vulnerabilities and stale-datedness, and creating a fork with the updated dependencies for you to take at any time.
    • Maintaining a catalog of dependencies and transitive/OS dependencies over time so you can always reproduce the build.
    • Optionally providing security fixes for dependencies from EOL languages, like Python 2.

Next steps:

In summary, self-vendoring is a proven solution for reducing security risk and avoiding version conflicts, but creating the infrastructure to allow you to vendor your dependencies at scale AND remain responsive is an expensive proposition. This strategy becomes exponentially more difficult to maintain in diverse environments which can significantly reduce time to market. To learn more about ActiveState’s managed distribution offering:

Contact Sales

Recent Posts

Scroll to Top