The Dangers of Dependencies

By: Michael R. Bagnall

Last Updated: November 2, 2025

We’re codependents. All of us. Every developer, every engineer, every product creator.

The internet is built on dependency. It’s the greatest strength and at the same time the greatest liability of building software.

Almost all modern software is built on the shoulders of dependencies. If it’s not, then you’re viewed almost as archaic. Vanilla PHP… What?!?! Javascript without a framework? Unheard of. In some for or fashion it’s just the way things are done.

So what is so bad about software dependencies? Nothing per se, but there are some inherent dangers in relying too much on other software to make your product or service a reality. As a developer and product creator, I’ve learned the hard way that going too far down the rabbit hole can lead to more time upgrading and maintaining your dependency leverage than innovating your product.

Probo.CI can help you manage your dependency issues. By applying depenecy updates in your code, you can unit and web test your dependency updates before you ever make it near production. If you have any questions about how Probo.CI can help you manage your dependencies, please shoot us an email.

So what about the dangers?

1. Updates that are difficult to keep up with logistically
2. The updates that never come or not resolved in a timely fashion
3. Obsoletion
4. When the free ride is over

Breakneck Update Velocity

Updates and revisions can happen quickly. You have a hard time keeping up. And with every update requires re-factoring,testing, review and re-deployment. More time. And as they say “Time is money, friend”.

The Snail Pace of Unresolved Issues

Conversely, when updates are lagged, delayed or the module becomes unsupported any the developer going AWOL, it can lead to a slow and stead slump into brokenness. Issues go unresolved. Security issues cause other problems and contributions to the project or newer features are left on the table. We’ve seen this with Probo where we’ve had dependencies version themselves out of support with the upgrade of other technologies and we’ve had to find other solutions that are usually not a 1:1 fit.

The Issue Queue Can Be Tricky

Sometimes bugs and issues may have patches or remediations in the pipeline, but never seem to be deployed. This leads to manual patching or having to seek alternatives. Which means you get to maintain how and when the software is patched in your project. More overhead.

Beware of the Tow Truck

Software developers can pull their dependencies from repositories or make them premium. This means what you leveraged as open source, you will now have to pay a licensing fee to use. This happened just recently with Bitnami. All of their open source containers and helm charts were placed in legacy status in favor of a subscription model. This means the images are there, but no more updates which will ultimately lead to security issues.

I get that all projects are not on the same development schedule. But allowing your dependencies to dictate your development schedule can be expensive. This becomes imperative in deciding what to use and when to roll your own.