Use dependency risk arithmetic without inventing independence

An adverse dependency event might mean a known exploitable defect in the deployed path, unauthorized bytes entering a build, or a compromised package script executing during installation. These are different events with different conditions and consequences. A vulnerability identifier in a package does not alone establish reachable exploitation in one deployment, while absence of a known identifier does not prove safety. Specify package-version-artifact identities, target, execution phase, privileges, and the time period considered before assigning any probability or priority to the graph.

Deduplicate shared identities when counting components, but retain their edges and contexts. One parser used by ten services is one component identity with a broad impact path, not ten independent chances of that same component being compromised. Conversely, two versions or platform artifacts can need separate analysis. Build-time tools matter even if absent from the runtime image: a compromised generator can affect produced code. A small direct manifest can therefore conceal a substantial transitive input set. Closure and influence evidence help locate relevant surfaces; they do not establish that every component has the same likelihood or impact.

If adverse events are independent with a common probability p, the chance of at least one is one minus the chance that all are absent. This familiar expression can illustrate accumulation but should not be applied to a real supply chain merely because the components have different names. Shared publisher credentials, source hosts, compiler images, or update automation introduce common causes. An adversary may also choose targets based on their influence, violating a uniform random-event picture. Record hypothetical values as hypothetical; do not label the resulting percentage a measured security posture.

Expected counts and probability of any event are also different quantities. Linearity of expectation permits adding event probabilities for an expected number without requiring independence, but that does not determine how events cluster or the impact of one. Two graph designs can share the same expected count while one has a single common failure capable of affecting every output. Use the model to ask which shared dependencies or authorities dominate the recovery problem. Combine inventory and exposure evidence with control effectiveness, rather than optimizing solely for a smaller component count.

Review the permissions and effects of the build and runtime contexts. A package limited to an isolated transformation differs from a script holding release credentials. Separate input approval, build isolation, artifact verification, and deployment policy because they constrain different paths. A control can reduce one modeled event while leaving a common compromised builder untouched. Check downstream artifact bindings and recovery procedures so a detected problem can be scoped and replaced. Numerical ranking can support prioritization, but its assumptions and uncertainty belong beside the number, especially when component identities and known advisories are incomplete.

The probability lab displays the independent equal-p model exactly. For each separate view, Reset, set both p=0.01 and n to 10 or 30, predict the zero-event bar, then inspect. Interpret the complement as the model's chance of at least one adverse event. No compromises are sampled and no package is analyzed. Shared-source or shared-builder failures can invalidate the independence interpretation, so the diagram is useful as a conditional calculation rather than proof that a particular dependency graph has the displayed risk.