ProofwrightScenario

Scenario: a poisoned dependency

A popular package ships a malicious version. Detect exposure from the SBOM, contain, and communicate — calmly.

A popular dependency ships a malicious version — detect your exposure from the SBOM, contain it, and communicate calmly instead of guessing. Related demos: Scenario: responding to a new CVE in minutes and Scenario: when an open-source dependency goes dark.

News breaks that a widely used package published a compromised release. Across the industry, teams start a frantic manual audit: do we even use this? With a living SBOM, that question is a lookup, not an all-nighter.

Are we exposed?

Monitoring flags the malicious version and checks it against every product's inventory, direct and transitive.

ProductVersion presentExposed?
Console[email protected]Yes — malicious
Agent[email protected]No (< affected)
PortalNot present

Contain it

  1. Pin to a known-good version. Roll Console back below the compromised release and rebuild.
  2. Rotate what it could have touched. Treat any secret reachable by the build as exposed and rotate it.
  3. Record the VEX. Mark the affected product and the fixed version, with the timeline.

Communicate

Because you know precisely which product carried the bad version and which never did, the customer notice is specific and honest — one product, one fixed release — not a defensive "we're investigating" that invites worse assumptions.

Value
Products affected1 of 3
Fixed version[email protected]
Secrets rotatedComplete
AdvisoryPublished
A supply-chain attack is a drill you either rehearsed or didn't. The SBOM is what turns "are we affected?" from a week of dread into a morning's work.

Proofwright makes the exposure question a lookup.

this is Proofwright

It's live.

See the real thing at Proofwright.