Skip to content

Substrate Risk Release Gate

Release gate — instantiates Substrate Lineage Risk Audit

A pass/block control at the release point that refuses to ship substrate whose inherited risk is unaccounted-for or exceeds a blast-radius-scaled bar.

A Substrate Risk Release Gate is the control that stands in the deploy path and turns the audit's findings into an enforceable go/no-go. It does not discover inherited risk — the inventory, scan, and provenance record do that — it decides what happens when they surface something: accept, block, or waive under a named signer. Its defining move is that the pass bar is scaled by blast radius: the same inherited vulnerability faces a strict bar in a component that sits in the authentication path and a lenient one in an isolated internal tool, because the question the gate asks is not "is this risky?" but "how far would a compromise of this substrate, here, actually reach?" It is the archetype's point of teeth — the place where an inherited risk that everyone can see finally has to be reckoned with before it ships.

Example

A bank's deployment pipeline includes a substrate-risk gate. Its rule: no artifact ships carrying an unresolved critical inherited vulnerability without a signed, time-limited waiver — and the waiver bar scales with reach. When a release of the customer-facing authentication service arrives still carrying a critical finding from the transitive scan, the gate blocks it: the blast radius of that component is the whole login path, so the bar is "fix it." A week later a medium-severity inherited flaw in an internal analytics dashboard reaches the same gate; because its blast radius is contained and low, the gate permits it to ship under a dated waiver signed by the owning team.[1]

The gate discovers nothing new here — the scan already found both flaws. What it adds is that neither can quietly slip into production on momentum: each inherited risk is forced into an explicit, owned, blast-radius-weighted decision at the last responsible moment.

How it works

  • Require the audit inputs. The gate first checks that the substrate was examined at all — an inventory, a scan result, a provenance record exist — and fails closed if they don't.
  • Size the blast radius. For the substrate in question, model how far a compromise would propagate: what it can reach, what trusts it, what depends on it. This sets the bar.
  • Apply the residual-risk rule. Compare the unresolved inherited risk against the blast-radius-scaled threshold and resolve to pass, block, or waive.
  • Bind the decision to an owner. Any waiver carries a named signer and an expiry, so an accepted risk is accountable and time-boxed rather than permanent and anonymous.

Tuning parameters

  • Severity thresholds — the risk level that triggers a block. Stricter thresholds stop more but generate more friction and more pressure to bypass.
  • Blast-radius weighting — how sharply reach tightens the bar. Steep weighting concentrates scrutiny on high-reach substrate; flat weighting treats an internal tool like a payment path.
  • Waiver policy — who may sign, for how long, and with what evidence. Loose waivers keep delivery moving but hollow the gate out; tight ones bite but can bottleneck.
  • Fail-open vs. fail-closed — whether missing audit data blocks the release or merely warns. Fail-closed is safer; fail-open keeps the pipeline flowing at the cost of the gate's whole point.
  • Coverage requirement — whether an SBOM and scan must exist for a release to be eligible at all, independent of their findings.

When it helps, and when it misleads

Its strength is converting an audit into enforcement: with a gate in place, nothing inherited ships unexamined, and every accepted risk is a dated, signed, blast-radius-weighted decision rather than a silent default.

Its failure modes are the ones every gate suffers, sharpened by inheritance. Under deadline pressure gates get bypassed — the override becomes the norm and the control decays into theater. A gate only enforces what it is fed, so a risk that never reached the scan sails straight through a green gate. And waiver sprawl is the slow death: enough standing exceptions and the bar is a formality. The classic misuse is the rubber-stamp waiver signed to make a decision already taken — the gate run backwards to justify shipping rather than to test it. The discipline is to make waivers expire and be logged, fail closed on missing audit data, and review the waiver ledger itself as a risk surface, because a gate that never blocks anything is not protecting anything.

How it implements the components

This gate fills the decision-and-adjudication side of the archetype's machinery — the components that turn findings into an enforceable choice:

  • residual_inherited_risk_decision — it makes the explicit accept / block / waive call on inherited risk at the release point, and binds it to a named, time-limited signer.
  • substrate_blast_radius_model — it sizes how far a compromise of the substrate would propagate and scales the pass bar to that reach, so scrutiny tracks consequence.

It does NOT find the risks it adjudicates — that's Transitive Vulnerability Scan and Software Bill of Materials with Lineage — nor contain a risk it chooses to let through — that's Sandbox or Adapter Wrapper. The gate decides; its siblings detect and contain.

Notes

The gate's integrity lives or dies on two settings most teams under-tune: whether it fails closed when audit data is missing, and whether waivers expire. A gate that waves through un-audited substrate, or that lets waivers accumulate forever, still exists on paper while protecting nothing — so the waiver ledger deserves periodic review as its own inherited-risk surface.

References

[1] SLSA (Supply-chain Levels for Software Artifacts) is a real, published framework of graded requirements for securing software supply chains, including provenance and release controls. It is referenced here only as an example of the class of supply-chain release-gating practice this mechanism belongs to, not as the source of any specific rule above. ↩