Your logistics partner's webhook is trusted on a shared secret you cannot change — how do you model and bound a compromised partner?

## The move this question is testing Most integration threat models quietly assume the far side is honest and only ask whether an outsider can get in. The compromised-vendor scenario removes that assumption: you grant the partner exactly the trust the design gives them, then ask what an attacker in possession of that trust can accomplish. It is the vendor equivalent of assuming breach, and it is the difference between a model that produces reassurance and one that produces decisions. ## What the current design actually proves A shared secret plus an IP allowlist establishes, at best, that a request arrived through a channel the partner controls. It does not establish: - that the *event described* occurred — the payload is an assertion, and authentication of the sender never validates the claim; - that the sender was the partner's production system, when their staging shares the secret and the egress range; - that the message is fresh, unless you enforce timestamps and a replay window; - that the partner's own environment is uncompromised, which is precisely the thing under test. The first and second points are where teams lose the most. "The webhook is signed" is a statement about the envelope; the business logic behind it is what converts the envelope into a refund. ## Naming the impact in the right units Delivery and damage-claim events drive two things: **money** (claims paid, refunds issued, shipping costs credited) and **audit truth** (your record of what happened to a shipment, which downstream disputes and reporting rely on). In STRIDE terms the dominant categories are spoofing at the boundary and tampering with the state those events write, with repudiation close behind — once forged events land in the ledger, distinguishing real from fabricated after the fact may be impossible. Availability barely features, and that is worth saying out loud: a threat model that only produces "they could DoS us" has not looked at what the integration is *for*. An attack tree helps make the branches explicit: ``` Goal: extract money via forged claim events OR |-- obtain the shared secret | OR | |-- compromise partner production | |-- compromise partner staging (same secret) | +-- obtain it from a partner employee or config store +-- reach the endpoint from an allowed address AND |-- egress from the partner's address range +-- send a well-formed claim payload ``` At an OR node the attacker takes the cheapest child; at an AND node every child must be satisfied. Reading it that way shows the allowlist as one conjunct in a branch the attacker mostly already satisfies, not as an independent defence. ## Bounding it when you have no leverage The honest constraint in this scenario is that you cannot make the partner better. You can only change your side, and that is where the interesting principal judgment sits. The moves worth arguing for: - **Demote the event to a claim.** Nothing partner-asserted should mutate financial state directly. Land it in a pending state that a reconciliation or a second signal promotes. - **Reconcile against something the partner does not control** — your own scan data, carrier tracking you fetch yourself, or customer confirmation. Independence is the whole value; a second feed from the same partner is not one. - **Cap the blast radius numerically.** Per-event, per-hour and per-account limits on value, with anything above them queued for human review. A cap turns an unbounded loss into a bounded one and does not require the partner's cooperation. - **Enforce freshness and idempotency.** Timestamped, single-use identifiers with a narrow replay window remove trivially cheap branches of the tree. - **Separate their environments.** Insist on a distinct endpoint and credential for non-production traffic even if you cannot audit them; if they refuse, treat production as reachable from their staging and say so in the model. - **Own the off switch.** Rotation and disablement must be executable by you, alone, within minutes, and rehearsed. A control you can only exercise by filing a ticket with the party you are worried about is not a control. - **Detect on shape, not just volume.** Sudden changes in claim rate, value distribution, or the set of accounts touched are what a forged-event campaign looks like from your side. ## Where this stops Two adjacent activities are not this question. Assessing the partner against a control framework or sending them a questionnaire is procurement's risk process and does not change your diagram. Writing down "the partner protects the secret" as an inherited assumption is an artifact-hygiene practice worth doing, but the point here is the opposite instinct: model what happens when the assumption is false rather than filing it. ## Closing the loop as a lead The deliverable is a decision, not a list. Say which mitigations you are implementing, what residual risk remains after them, who accepts it by name, and what would trigger revisiting — a contract renewal, a change in claim volume, a security incident disclosed by the partner, or a material change in the integration. A threat model of a vendor integration that ends without an owner for the leftover risk has produced a document; one that ends with an owner has produced a decision.