Modern software is rarely built in isolation. Applications depend on frameworks, libraries, package registries, build tools, container images, CI/CD services and cloud platforms. Each dependency can save development time, but each one also introduces another external relationship that must be understood, monitored and trusted.
In 2026, software supply-chain attacks have continued to demonstrate how effectively attackers can bypass traditional network defences by targeting the tools and components trusted by development teams.
Instead of attacking a completed application directly, threat actors can compromise a maintainer account, package registry, build workflow or publishing credential. Malicious code can then be distributed through apparently legitimate software updates and executed automatically on developer workstations, build servers and production systems.
This changes the nature of the risk. A dependency does not need to contain a known vulnerability when it is selected. It can become dangerous later because its ownership, build process, publishing credentials or downstream dependencies have been compromised.
Dependency count is also a security decision
Dependencies are often discussed as implementation details. We believe they should also be treated as architectural and security decisions.
Installing a package can mean trusting considerably more than the code exposed by its public API. It may also mean trusting:
- its maintainers and future maintainers;
- their source-code hosting accounts;
- their CI/CD and release workflows;
- the security of the package registry;
- installation and build scripts;
- its direct and transitive dependencies;
- future versions selected by the package resolver;
- the continued availability and maintenance of the project.
A small utility package may therefore introduce a much larger trust relationship than its visible source code suggests. A project with a few dozen declared dependencies can ultimately rely on hundreds or thousands of transitive packages.
Every additional component expands the potential attack surface that must be monitored, patched, audited and understood. It also creates another opportunity for a compromised account or publishing process to affect the finished system.
Every dependency must earn its place in a business-critical system.
Our approach: minimal, deliberate dependencies
ENCOM does not pursue minimal dependencies because of a “not invented here” philosophy. Nor do we believe that all external software is inherently unsafe.
Mature open-source projects, commercial platforms and established frameworks can provide enormous value. The important question is whether a dependency provides enough value to justify the trust, operational risk and long-term maintenance obligation that it introduces.
Our default position is therefore not "never depend on anything". It is "every dependency must earn its place in a business-critical system".
Where a small, stable capability can be implemented clearly and safely within the application, we consider doing so rather than importing a large package or framework. Where an external dependency is the stronger choice, we adopt it deliberately and record why it exists.
We keep core business rules explicit and close to the application domain. External libraries may support the system, but they should not obscure the decisions, processes and data that the organisation depends upon.