Published Sep 13, 2026 • Updated Sep 13, 2026

Your Dependencies Are Part of Your Architecture

Most architecture diagrams have a comforting property: almost everything on them appears to belong to us.

We draw our applications, APIs, databases, queues, identity providers, cloud services, and network boundaries. We discuss which service owns which data, where traffic is allowed to flow, and what happens when a dependency becomes unavailable.

Then we open the actual repository.

The application may depend on hundreds of packages. The container starts from a base image maintained somewhere else. The CI pipeline downloads actions and plugins. The build pulls compilers, package managers, and binaries. Infrastructure modules arrive from registries. A library we chose directly brings twenty more libraries we did not choose directly.

Those components rarely appear on the architecture diagram.

But they can execute inside our build environment, ship inside our production artifact, inherit credentials, influence deployment, and become part of the software our customers ultimately trust.

That makes the software supply chain an architecture concern, not merely a vulnerability-scanning concern.

The Boundary of the System Has Moved

There was a time when it was easier to imagine an application as mostly code written by the organization that operated it. That has not been true for a long time.

Modern software is assembled as much as it is written.

That is not a criticism of open source or package ecosystems. Reuse is one of the reasons software teams can build sophisticated systems at all. Writing our own HTTP server, cryptography library, database driver, telemetry stack, UI framework, and serialization layer would usually make a system less secure and less maintainable, not more.

The architectural mistake is different. It is treating externally produced code as though it stops being an external dependency the moment a package manager places it inside our repository or artifact.

We would never integrate an external production API without thinking about ownership, availability, change, and trust. Yet a package can be granted something even more powerful: the ability to execute inside the application itself.

The logical system boundary therefore extends beyond the boxes we deploy.

It includes the path by which software becomes those boxes.

A Dependency Is a Trust Decision

When an engineer types an install command, the decision often feels local and reversible.

Technically, it may be a much larger decision.

We are trusting a package name to resolve to the intended project. We are trusting the registry. We are trusting the publisher's account. We are trusting the project's maintainers and release process. We are trusting the package's own dependencies. We are trusting that the artifact we download corresponds to the source we think produced it.

And sometimes we are trusting installation scripts to execute immediately on a developer workstation or CI runner.

This is why recent OpenSSF guidance describes package installation itself as an execution boundary. The organization is not merely downloading data. It may be admitting executable behavior into a privileged engineering environment.

That framing changes the question from "Does this package have a known CVE?" to something broader:

What are we trusting, why are we trusting it, and what could it reach if that trust turns out to be misplaced?

The Transitive Problem Is the Real Problem

Direct dependencies are relatively easy to reason about. Someone intentionally selected them.

Transitive dependencies are where the mental model starts to break down.

A team may believe it depends on twenty libraries while the resolved dependency graph contains hundreds or thousands of components. Some are maintained by large projects. Others may be maintained by one person. Some are deeply embedded in the ecosystem but almost invisible to the application team.

This is not inherently unsafe. Small open-source projects can be exceptionally well maintained, and large vendors can make serious mistakes.

The issue is visibility.

If an incident affects a transitive package tomorrow, can we answer which applications contain it? Which deployed versions contain it? Whether the vulnerable code path is reachable? Which artifact was built with it? Whether rebuilding today would silently resolve to something different?

If those questions require several teams, multiple scanners, spreadsheet exports, and a day of investigation, the organization does not really understand its software composition. It merely knows how to build it.

An SBOM Is an Inventory, Not a Security Strategy

Software Bills of Materials are valuable because they make composition visible. NIST's software supply-chain guidance and broader industry work have pushed organizations toward knowing what components exist in their software rather than discovering them only during an incident.

But an inventory is not the same thing as a control.

A list of ingredients does not tell us whether the kitchen was compromised.

An SBOM can tell us that a component is present. It does not, by itself, prove who built the artifact, what source produced it, whether the build environment was trustworthy, whether the artifact was modified after the build, or whether the component should have been admitted in the first place.

This is where provenance becomes important.

SLSA's build model focuses on increasingly strong evidence about how an artifact was produced. At its core, provenance answers remarkably practical questions: who or what built this, what process built it, and what inputs went into the build?

Those questions sound like security questions. They are also architecture questions because they describe the chain of trust between source code and production.

The Build System Is Production Infrastructure

Many organizations apply strong controls to production and surprisingly weak assumptions to the systems capable of changing production.

A CI runner may hold package-registry credentials, cloud deployment permissions, signing keys, repository tokens, or access to artifact stores. A compromised build process can sometimes bypass controls that would stop an attacker approaching the runtime from the outside.

That means the build system belongs in the threat model.

NIST's Secure Software Development Framework explicitly includes protecting software from tampering and unauthorized access, securing development environments, and maintaining trusted source-code supply chains. Its 2025 draft revision continued to emphasize secure and reliable development, delivery, and improvement across the software lifecycle.

Architecturally, I think the implication is simple:

The path to production deserves security boundaries comparable to production itself.

Build identities should be explicit. Permissions should be narrow. Long-lived credentials should be exceptional. Artifacts should move through a controlled path. A release should be traceable back to its source and build. Rebuilding should not mean casually asking the public internet for whatever happens to be newest today.

AI Makes the Admission Boundary More Important

AI-assisted development adds an interesting twist.

A human developer who needs a library may search documentation, compare projects, inspect maintenance activity, and then install one. A coding agent can reach the same decision much faster—and can potentially execute the installation itself.

Speed changes the economics of small decisions.

If agents can create projects, add packages, modify pipelines, generate infrastructure, and resolve errors autonomously, organizations may consume third-party software at a higher rate than their old review processes were designed for.

OpenSSF's 2026 guidance on dependency firewalls explicitly calls out AI agents: package requests from agents should be subject to the same controls as requests from humans, with provenance, transitive dependencies, and suspicious or newly published packages evaluated before installation.

I think that points toward a broader architectural principle.

We should not try to make every developer—or every agent—personally expert at software supply-chain security. We should make the safe path the normal path.

The Platform Should Become the Trust Broker

This is where platform engineering can do something much more useful than adding another portal.

An internal engineering platform can provide a controlled dependency path: approved registries, package caching, provenance verification, artifact signing, base-image management, dependency policies, automated updates, and clear exceptions when teams genuinely need something outside the standard path.

The goal is not to create a central committee that manually approves every npm package.

That would be secure in the same way disconnecting the network is secure: technically effective and organizationally unusable.

The better design is policy close to the execution boundary.

Known-safe packages flow normally. High-confidence malicious artifacts are blocked. Newly published or suspicious components can receive additional scrutiny. Internal package names cannot accidentally resolve from public registries. Base images come from a maintained catalog. Builds produce evidence automatically rather than asking teams to assemble compliance artifacts later.

Security becomes infrastructure rather than ceremony.

Fewer Dependencies Is Not Automatically Better

There is a temptation to respond to supply-chain risk with a simple rule: use fewer dependencies.

Sometimes that is exactly right.

A tiny utility package that saves five lines of straightforward code may not justify another external maintenance relationship. A framework added for one convenience function can carry disproportionate weight. Dependency sprawl increases patching work, upgrade pressure, and the number of places where trust enters the system.

But "build it ourselves" also creates a dependency—on ourselves.

Homegrown security libraries, parsers, authentication mechanisms, and infrastructure components can be far riskier than mature external projects. Internal code needs maintainers, testing, documentation, vulnerability response, and succession just like open source does.

The architecture question is therefore not dependency versus no dependency.

It is whether the capability is important enough to own, whether an external component is trustworthy enough to adopt, and whether we understand the long-term operational cost of either choice.

Dependency Health Belongs in Architecture Reviews

I would not turn architecture review into a package-by-package audit. That does not scale and is not where architects add the most value.

But architecture should establish the rules of the system.

For important workloads, I would want to understand:

Where can third-party code enter the engineering environment?
Which registries and artifact sources are trusted?
Are versions locked and are updates intentional?
Can we identify transitive components in deployed software?
Can an artifact be traced to source and build provenance?
What permissions do build systems and package-install processes have?
Who owns shared base images and critical framework dependencies?
How quickly can we answer "Where are we using this?" during an incident?
What happens when a critical dependency is abandoned?

These questions expose architectural coupling that a service diagram cannot show.

There Is Also a Business Continuity Problem

Security gets most of the attention, but dependencies create another form of risk: continuity.

What happens when an important project changes license? When a maintainer stops publishing fixes? When a package registry is unavailable? When an upstream project makes a breaking change? When a vendor is acquired and the product direction changes?

Architecture has always been concerned with external dependency risk. We routinely discuss the availability of payment providers, identity systems, cloud services, and SaaS platforms.

Software components deserve the same thinking.

A deeply embedded framework is not "just a library." It may shape the application's programming model, deployment model, observability, hiring needs, upgrade cadence, and ability to move in the future.

The more difficult a dependency is to replace, the more architectural it has become.

Architecture Is Ultimately About What We Choose to Trust

Good architecture is often described as managing complexity and change.

I would add trust.

Every useful system depends on things outside itself. Clouds, libraries, frameworks, protocols, vendors, open-source maintainers, build systems, and engineering platforms make modern software possible. The goal is not independence. Complete independence is usually an expensive illusion.

The goal is deliberate dependence.

We should know what we depend on, understand the consequences of that dependency, constrain what it is allowed to do, preserve evidence about where our software came from, and have a reasonable response when trust fails.

That is why I no longer think of software supply-chain security as a scanner sitting near the end of CI.

It is a property of how the system is assembled.

And if architecture describes the important structures, boundaries, dependencies, and decisions that shape a system, then the conclusion is hard to avoid:

The dependencies may be missing from our architecture diagram, but they are already part of our architecture.