A shared attack-tree subtree no longer fits every consumer as their systems diverge - how do you keep the library honest?

## Why drift is the defining risk of reuse A reusable subtree is a claim that several systems share the same decomposition of one sub-goal. Systems change; the claim quietly stops being true. Nothing in the model complains, because the tree still renders and still propagates a number. That is what makes drift the principal-level problem here: the failure is silent, and the artifact that goes wrong is not the diagram but the **priority order** people take from it. ## The propagation hazard, concretely An insurer shares an 'insider with legitimate read access walks out with a bulk extract' subtree between a CRM and the analytics warehouse fed from it. The adversary is a departing account manager; the asset is customer personal data. Later the warehouse gains row-level masking, so bulk extraction there yields far less. Someone updates the shared subtree's leaf to reflect the new difficulty. Now the CRM's tree - which got no masking - shows the same raised difficulty. The bulk-extract path looks harder than it is, its propagated value falls below other paths, and the CRM's real insider risk drops down the remediation list. Nobody made an error of reasoning; the edit was correct for the consumer who prompted it and wrong for the one who did not. This is the direction of failure to watch for: **a change made for one consumer lands in every consumer that shares the node.** The rule that prevents it is the same one that governs parameterisation: a change caused by *one system's* controls or architecture belongs in that system's attachment values, never in the shared shape. Only a change to what an attacker must fundamentally do belongs in the shared node - and that change should force every consumer to re-confirm rather than inherit quietly. ## Ownership, consumer lists, and review triggers Three pieces of governance do most of the work: - **A named owner per subtree.** Not the security team in general - a person. Unowned shared artifacts rot in exactly the way unowned shared code rots. - **A recorded consumer list.** Reuse only pays if you can answer 'which trees does this node hang under', because that is the blast radius of any edit and the worklist for any re-confirmation. - **Review triggers, not just a calendar.** A yearly sweep is fine as a backstop, but the real trigger is a consumer changing: a new authentication path, a segmentation change, a datastore gaining or losing a control, a workforce change in how people access the system. That last one produces the most embarrassing failure mode. A corporate library holds a 'phish a staff member into handing over a session' subtree written when everyone had laptops. It is re-attached to a warehouse application whose staff use only shared kiosk tablets, where the branch structure - personal mailbox, browser session, individual device - describes almost nothing that exists. The subtree is not merely mis-valued; it describes no consumer. The owner's job is to notice and either rewrite it against how those people actually work or retire it. ## Fork, parameterise, or retire The standing decision at every review: - **Parameterise** when the branches still hold and only the values moved. Cheapest option, keeps consistency. - **Fork** when the shape diverged. A payments company reusing a 'reach the signing-request path' subtree across card issuance and settlement will find one consumer sitting inside the audited cardholder-data segment with different reachable branches from the other. Bending one node to serve both makes it wrong for both. Two smaller, true subtrees beat one shared, hedged one - accept the duplication, it is the honest cost of a real difference. - **Retire** when no live system matches. Deleting a library entry feels like losing work, but a stale entry is worse than no entry, because people trust the library precisely because it is shared and reviewed. ## Making divergence visible rather than preventing it You cannot stop systems from diverging, so aim to make divergence loud. Practical moves: record per attachment which branches were pruned and which leaf values rest on a *specific existing control*, since those are the values that expire when the control changes; date each attachment and show that date next to the propagated result, so a reader can see the number is two years old; and treat any shared-node edit as a change request that notifies every consumer's owner rather than a silent save. A reasonable maturity signal is that the library shrinks sometimes. A library that only ever grows is one where nobody has been willing to say a subtree stopped being true. ## How to argue it in an interview The judgment being tested is whether you understand that reuse trades one problem for another. Un-shared trees are inconsistent but locally honest; shared trees are consistent but can be uniformly wrong. That trade is worth taking only if someone owns the shared side. If the organisation will not fund an owner, the correct principal-level answer is to keep the library small - two or three subtrees that genuinely recur - or not to run one at all, rather than to accumulate shared nodes that nobody can vouch for.