pattern·published·2 exhibits

Emergent Primitive

Individually safe components that compose into an attack. Nobody owns the intersection.

A bug that lives inside one component has an owner. Somebody wrote the code, somebody maintains it, somebody will patch it. The report goes to the owner, the fix goes into the release, defenders follow the advisory. The ownership boundaries make the fix loop possible.

An emergent primitive does not live inside any one component. It lives in the COMPOSITION. Five products, each working exactly as designed, each with clear individual ownership, produce an attack primitive that none of them would have alone. The bug report asks, sensibly, which vendor to address it to. The answer is: all of them, none of them, and the integrator who assembled the combination. The integrator was probably the customer.

Mechanism

Modern systems are assemblies. A single production service might combine a web framework, a JSON parser, a message queue, an auth provider, a container runtime, an orchestrator, a service mesh, a logging pipeline, and a handful of language-level libraries. Each of those components has its own security model, its own threat assumptions, and its own patch schedule. The assembly has no single security model. The assembly is what the operator produced by wiring the pieces together.

The pattern arises when the wiring itself enables a primitive that no individual component produces. Component A exposes an administrative interface that is safe by assumption because A was designed to live inside a trusted network. Component B offers a serialization feature that is safe by assumption because B was designed to be fed trusted input. Component C provides an HTTP bridge to A's admin interface because an integrator needed it. Component D accepts HTTP from the internet because D is an internet-facing edge. The chain D to C to A to B takes attacker-controlled HTTP and converts it into deserialization at B, which yields code execution.

No component did anything wrong. Each component's assumptions were correct within its designer's scope. The assumption that failed was the one that spanned them all, and nobody owned that assumption.

What makes the pattern specific is the OWNERSHIP VACUUM. The advisory for an emergent primitive has to name a combination, not a product. The fix is not a patch but a rearchitecture. The detection is not a rule but an architectural review. The pattern is structurally uncomfortable because the disclosure pipeline is built around single-component bugs, and this is not that.

Exhibits

tj-actions: Mutable Tags Were Always a Lie. The tj-actions incident is an emergent primitive across git, GitHub Actions, and the workflow ecosystem. Git tags are mutable by design, which git owns. GitHub Actions resolves action references by tag, which GitHub owns. Workflows run with access to repository secrets, which the repository owner configures. Third-party actions are composed into workflows by whoever authored the workflow, often an integrator with no control over the three upstreams. The primitive (rewritten tag plus automatic re-resolution plus secret exposure) is the composition. No single fix from a single vendor closes it. The defender's work is to push pinning by SHA, a workaround at the composition layer, because that is the only layer with a single owner (the workflow author).

Boundaries

Not every multi-component attack is emergent-primitive. An attacker who chains a known OS bug with a known browser bug to escape a sandbox is combining pre-existing primitives. The primitives existed individually; the chain is the exploit mechanics, not a new primitive. Emergent-primitive requires that the PRIMITIVE ITSELF is a property of the composition, not assembled from primitives each component had on its own.

Not every integration bug. A vendor whose product mishandles input from a second vendor's product is ordinary integration breakage, typically owned by whichever product parsed the input wrong. Emergent-primitive specifically describes the case where all involved components parsed correctly and the problem lives above them.

Not every supply-chain compromise. A maintainer-account-compromise that ships malicious code has a clear owner: the compromised maintainer and the registry that served the code. Those incidents have attribution. Emergent-primitive incidents have attribution vacuums.

Defender playbook

Map the composition boundaries in your stack. For every integration point that crosses a vendor boundary, identify which decisions on each side enable the integration and whose threat model those decisions come from. Decisions that depended on an upstream threat model that is no longer accurate (the component is now exposed on the internet, the input is no longer trusted) are the candidate sites for emergent primitives.

Ask who owns the combination. If the answer is "us, the customer, because we integrated it," you have identified the ownership vacuum. The customer is the last line of defense against bugs that are nobody else's to fix. Budget for the customer's share of the work: architecture review, network segmentation, compensating controls, monitoring that spans component boundaries.

Treat internet exposure as a composition-breaking change. A component designed to live inside a trusted network has a threat model that assumes the network is trusted. Putting it on the internet, or putting it behind a bridge that effectively puts it on the internet, changes the component's security properties without changing its code. The new properties are the composition's problem.

Watch the advisory streams for named-combination advisories. Real disclosures of emergent primitives sometimes come from independent researchers who found the chain, because the vendors individually had no incentive to look. Those advisories read differently from single-product CVEs, they name a combination, suggest configuration changes rather than patches, and often arrive without a CVE because no single vendor took ownership.

Do not assume a vendor fix closes the chain. If the pattern is emergent, the vendor who patched owned one component. The chain may still work via the other four. Verify by rebuilding the chain against the patched version, or by reasoning about whether the patched component's change plugs any path in the composition.

Kinship

Design Debt Driver. Design-debt-driver is vertical: one component repeatedly produces CVEs of the same class. Emergent-primitive is horizontal: multiple components compose into a primitive nobody owns. A component that is a design-debt-driver often participates in emergent primitives, because its recurring bug class is one of the compositional ingredients attackers keep reaching for.

Trust Inversion. Emergent primitives frequently produce trust-inversion outcomes: the composition authorizes actions that none of the components would authorize alone. The authorizing mechanism is the composition itself. Trust inversion is the consequence; emergent-primitive is the generator.

Unauth Write To Execution Path. A specific recurring composition: component A accepts writes without auth, component B executes files from the directory A writes to. Neither component is broken individually. The composition produces pre-auth RCE. Unauth-write-to-execution-path is a named instance of emergent-primitive with enough recurrence to merit its own entry in the taxonomy.

The attack lives in the spaces between your inventory items. Your inventory is components. Your attack surface is compositions. Most security programs measure the first. Attackers exploit the second.