Fear Is the Mind-Killer. Dependencies Are the Build-Killer

· Updated August 11, 2026 by AvlCodeMonkey Share

Fear Is the Mind-Killer. Dependencies Are the Build-Killer

Remember when adding a package was just:

npm install some-random-thing

What could possibly go wrong? Well... Shai-Hulud happened. The recent Shai-Hulud supply-chain attacks are a particularly nasty reminder that every dependency is an invitation into your build environment. Those attacks compromised legitimate packages and used stolen credentials to spread to other packages.

He Who Controls the Dependencies Controls the Build

Every dependency adds more code to trust, more vulnerabilities to monitor, and more updates to manage. This doesn't mean "never use dependencies" or "always re-invent the wheel". We'd all still be writing our own HTTP clients and arguing about JSON parsers. It means minimize them.

When you do need a dependency, consider who maintains it and how much trust you're giving it. For .NET developers, something like Microsoft's Microsoft.FeatureManagement is a very different proposition from grabbing an obscure package maintained by someone with an unpronounceable alias. Microsoft isn't magically immune to vulnerabilities. No one is. But established vendors with mature security practices, release processes, and large communities can be a more comfortable place to put your trust.

The Spice Must Flow. Your Dependencies Don't Have To

Don't blindly consume latest. Pin dependencies to specific versions. Keep lock files under source control. Update deliberately. Review dependency changes instead of letting the package manager summon whatever happens to be waiting in the desert.

  • Remove dependencies you don't actually need.
  • Audit direct and transitive dependencies.
  • Monitor for known vulnerabilities.
  • Use trusted package sources.
  • Verify package provenance and signatures where available.
  • Keep CI/CD credentials locked down.
  • Give build processes only the permissions they actually need.
  • Treat unexpected dependency updates as something worth investigating.

Yes, We're a Dependency Too

FeatureFlags.app is a third-party dependency. We know. The irony is not lost on us. That's why the client library is intentionally small and open source. You can inspect it yourself - FeatureFlags.Client on GitHub.

The goal isn't to eliminate every dependency. The goal is to understand what you're trusting and keep that trust as small as practical.

Walk without rhythm and maybe the worm won't find you.