Supply Chain Dependency

Every system inherits work it did not create. Capability, maturity, and delivery speed arrive with consequences the team does not govern. The boundary then moves when a maintainer withdraws or a contract lapses, not when the project is ready. Four dimensions keep that trade separable and priceable: Form, Governance Distance, Assurance, and Replacement Cost. They resolve into a dependency ledger I keep — one entry per inherited layer, closing with rationale, owner, evidence, and the event that reopens the choice. It sizes inherited leverage against what a layer’s failure costs, before an incident forces the question.

Dependency Necessity

If you wish to make an apple pie from scratch, you must first invent the universe. — Carl Sagan, Cosmos, Chapter 9, “The Lives of the Stars”

Sagan’s apple pie makes the boundary visible: the cook inherits a universe. To make something from scratch is to choose where the work begins, not to remove what came before. Every team does the same. Each starting point fixes part of the result before the first product decision is made.

A layer is one part of a system a project can either build or take from outside. Scope management means deciding, per layer, whether to take the description of a thing, the thing itself, or both. That decision reaches past delivery speed. It fixes what enters the system, who governs it, what evidence supports it, and what leaving will cost.

Four dimensions keep those consequences separable and reviewable:

• Form — what crosses the boundary.
• Governance Distance — who may change it.
• Assurance — what is actually proven.
• Replacement Cost — what leaving costs.

The dimensions correlate; none determines another. A layer can be imported and well evidenced, or built and poorly evidenced. Recorded separately, they price the choice. Collapsed into a single verdict, they hide it.

Form

Form is what actually crosses the boundary: a description of how something works, or the thing itself. Taking the description leaves the construction work with the team and keeps the result under direct control. Taking the thing buys delivery time and places someone else’s construction inside what ships.

The description-led path has a narrow domain. It needs a public, reasonably stable description whose requirements can be exercised repeatedly. Wire formats, encodings, and protocol grammars meet that condition. Query planners, rendering engines, and schedulers do not, because what they sell is accumulated craft rather than a statable rule. Where no description is on offer, the choice is not between two forms; it is between importing and forgoing.

CBOR: Decoder Or Definition

A product that must read CBOR^[1] can import a parsing library or write its own decoder against the published format. The specification does not settle the bill. RFC 8949’s worked examples illustrate the format without establishing conformance, so a team implementing against it owes a corpus and a harness as well as a decoder. The cbor/test-vectors repository supplies part of that corpus, translating Appendix A of the predecessor RFC 7049 into machine-processable vectors. Retained control is largely paid for there.

Depth narrows the field further without closing it. A decoder in firmware may have to run without a dynamic allocator, the runtime facility that hands out memory. RFC 8949 explicitly targets constrained nodes, and implementations such as Rust’s minicbor support no_std environments. A local decoder stays proportionate when available libraries exceed the required subset, memory budget, certification boundary, or security model.

Governance Distance

Governance Distance is how far the authority to change, release, and operate something sits from the team. Building holds that authority inside the team and buys unilateral control. It does not buy freedom from cost, since maintenance, security review, and specialist continuity remain owed. Importing usually places the roadmap outside the team, though vendoring or a maintained fork creates a hybrid. Renting adds an external operator and a contract to the running system.

The dimension records distance, not a full rights inventory. Record a right explicitly when it changes realistic exit cost: source or diagnostic access; modification, release, or operating authority; data export; and termination terms.

A Rented Capability’s Exit Terms

Renting makes a supplier’s operations and contractual rights part of the running system. NIST SP 800-146 treats cloud service agreements in terms that include availability, termination, and data-retention policies. The rights worth recording generalize beyond cloud, and NIST’s supply-chain guidance treats source and test access, alternative suppliers, and continuity as the same class of concern. Those risks are not unique to renting, since an internal platform or supported commercial package can create analogous continuity exposure. The trade stays constant: work not performed locally, against control not held locally.

Assurance

Three claims travel under the word reliable, and a serious record keeps them apart. The definitional claim is that something satisfies stated requirements. The empirical claim is what it has survived: real failures, adversarial input, and operating load. The operational claim is who can observe, diagnose, repair, and change it, and under what rights.

None implies another. A published description makes a conformance claim testable without supplying any production history. Ownership confers no operational assurance a team has not actually built. Conformance proves only the requirements and cases a corpus exercises, and it describes what ships only when the delivery path binds the tested artifact to the released one. An entry claiming all three without separate evidence has hidden the trade rather than priced it.

xz And SQLite

Importing an executable artifact adds a surface no description has. The original disclosure of the xz backdoor reported a build-time injector present only in the 5.6.0 and 5.6.1 release tarballs, while obfuscated files carrying the bulk of the exploit sat in the repository. The injector ran during configure and consumed those files, and that gap between repository and release artifact was a material attack surface, not the whole attack. SLSA 1.2 defines provenance as verifiable information about where, when, and how an artifact was produced, which makes that path inspectable but establishes lineage rather than safety. Valid provenance describes a faithfully built malicious source as accurately as a benign one.

That burden does not erase what an implementation buys. SQLite’s testing documentation reports four independent test harnesses, simulated memory and I/O failures, crash testing, fuzzing, and cross-engine logic tests. Those figures are project-reported and configuration-sensitive, but they describe inspectable accumulated work a local replacement would have to reproduce or consciously forgo. The production exposure of every other operator comes with it, and conformance establishes a narrower claim that does not substitute for maturity. The asymmetry that survives is narrower: a description does not enter the shipped system as code on a package update, and an imported implementation reopens a review whenever one is offered.

Replacement Cost

Replacement Cost turns on a fact the other three dimensions do not carry. A team does not always choose when the boundary moves. Maintenance can end, a supplier can withdraw, a contract can lapse, and a security finding can force a migration on someone else’s schedule. The cost is real whether or not it was priced, and a cost first discovered at the trigger is a cost the project never priced.

Descriptions age differently from implementations. A stable published description stays usable even after its standards process stops evolving, though it still collects errata, successors, and registry additions. The asymmetry is a cost to price, not a verdict to pronounce. Rebuild, migrate, tolerate interruption, export data, renegotiate: each is recorded per layer, alongside the event that would trigger it.

serde_cbor’s Archived Repository

In November 2021 the Rust advisory database issued RUSTSEC-2021-0127, classifying serde_cbor as unmaintained. Its author had archived the repository and proposed ciborium and minicbor as alternatives. The advisory described a maintenance-status event, not a disclosed code vulnerability. The boundary moved when maintenance ended, not when importing teams were ready, and the migration work landed on the users.

Conway’s Consequence

Something built by one organization arrives carrying that organization’s seams. Conway’s Law^[2] holds that a system’s design mirrors the communication structures of the groups that build it. Extension points, defaults, and priorities reflect their authors’ coordination. Those choices become the adopter’s constraints, and they are inherited without negotiation.

Tag Numbers 0–23

Applying Conway’s Law to a client that merely adopts an artifact is an inference, not the law itself. The related mirroring literature finds correspondence across firm boundaries, with exceptions. CBOR’s tag numbers show what the inference points at.

Under RFC 8949’s encoding, a tag number from 0 to 23 fits in the tag’s first byte, while a value from 24 to 255 needs one additional byte. The IANA registry allocates the compact 0–23 range under Standards Action, which RFC 8126 defines as assignment through an IETF-stream Standards Track or Best Current Practice RFC. The encoding makes the short range valuable; the standards process governs who receives it. A project adopting the format inherits both facts.

Inheritance Leverage

The four dimensions describe one transaction from four sides. Read together, they describe leverage: work a team does not perform, in exchange for control it does not hold. Leverage is not a hazard to be minimized, and it is not a discount to be maximized. It is a position, and a position has to be sized.

Balancing Risk And Opportunity

Every inherited layer buys capability the team did not fund and imports exposure the team does not govern. Both move together, and neither can be taken alone. The gain is real: imported maturity carries the production exposure of every other operator, and no local rebuild reproduces that at comparable cost. The exposure is equally real: an artifact the team cannot change is an artifact that changes on someone else’s schedule.

The balance is not struck by preferring one side. It is struck by matching the amount of leverage to the criticality of the layer and the cost of interruption. A layer whose failure is merely inconvenient tolerates distance, thin evidence, and an unpriced exit. A layer whose failure stops revenue, breaks a contract, or endangers people tolerates none of those, and that is where the description-led path and explicit rights earn their cost.

No universal build-or-buy rule follows. A cost that varies with depth, capability type, control, and evidence cannot be answered by a position. It has to be recorded, layer by layer, by the people who will pay it.

The Ledger

An SBOM identifies software components and their dependency relationships, and it can populate the inventory behind some imported entries. It is not this record. It does not cover description-only or rented layers, authority over change, the assurance evidence a project relies on, or the cost of exit.

The ledger holds one entry per inherited layer. Each entry names the layer, records the four dimensions, and closes with a Decision Record. That record separates selection rationale from assurance evidence, and names the owner, the date last reviewed, and the event that reopens the choice. Hybrids are recorded by the control actually held at that layer, not forced into a pure category.

Device-Link CBOR Decoder (Illustrative)

• Form — Imported specification (RFC 8949); built implementation.
• Governance Distance — Decoder team-built. Standard and registry externally governed.
• Assurance Evidence — Definitional: corpus seeded from RFC 7049 vectors; harness recheck of named requirements. Operational: team can inspect and repair. Empirical: none claimed.
• Replacement Cost — Extend or replace the decoder. Expand and rerun validation. Absorb certification or release delay.
• Decision Record — Rationale: a bounded wire format and control needs justify a local implementation. Owner: embedded-platform owner. Reviewed: set at adoption. Reopen on: standard or registry change, target change, security finding, failed vector.

Managed Identity Service (Illustrative)

• Form — Implementation.
• Governance Distance — Rented. Supplier operates the service; client owns configuration and integration.
• Assurance Evidence — Operational: supplier service commitments, client monitoring, support history, tested recovery procedures. Empirical: incident and availability history, where recorded. Definitional: none claimed.
• Replacement Cost — Migrate identities and integrations. Export data and metadata. Replace proprietary interfaces. Absorb interruption. Renegotiate or execute the exit plan.
• Decision Record — Rationale: supplier operation is worth the accepted continuity and exit burden. Owner: platform or security owner. Reviewed: set at procurement. Reopen on: material outage, deprecation, contractual change, control failure, exit-test failure.

The managed-identity entry is a template, not evidence about a named supplier. Record only commitments, history, export paths, and recovery tests the project has actually verified. NIST’s guidance to review plans at lifecycle milestones, gate reviews, and significant contracting activities indicates when to consult the record: adoption or procurement, renewal, dependency upgrade or release, incident review, and exit testing.

Before The Incident

Undocumented, these decisions surface under incident pressure as a question nobody answers quickly: is the behavior ours, the supplier’s, or an interaction between the two? The ledger exists before that moment. It prescribes no preferred position, only a record of who decided, on what evidence, and what the exit costs. It serves the people who own the cost of interruption as directly as the people who build the system.

A completed ledger leaves four questions:

1. Where has this project inherited an implementation when a description and a bounded local build would have served?
2. Where was imported maturity worth more than the control given up?
3. Which assurance claims have evidence, and which fields remain deliberately empty?
4. What event will force each boundary to be reviewed, migrated, or replaced?