Skip to content

Core concepts

EmbargoGate API manages each vulnerability advisory as a record that moves through a strict state machine. The state machine controls who can see an advisory and when it can be published.

The CRA requires manufacturers of products with digital elements to handle vulnerabilities throughout the product lifecycle and to report actively exploited vulnerabilities to the relevant CSIRT and ENISA. EmbargoGate API models that obligation as a pipeline: intake, verification, a controlled embargo period, and publication.

NIST SP 800-161 covers cybersecurity supply chain risk management. EmbargoGate API applies it by ingesting SBOMs, so that a verified vulnerability can be traced to every product that contains the affected component.

SUBMITTED ──► VERIFIED ──► EMBARGOED ──► DISCLOSED
│
└──► REJECTED
StateMeaningVisible to
SUBMITTEDA report has been received but not yet assessed.Submitter and triage team
VERIFIEDThe vulnerability is confirmed and affected components are identified.Submitter and triage team
EMBARGOEDA fix is in progress. Details are shared only with the coordination group until the embargo ends.Coordination group (time-bound)
DISCLOSEDThe advisory and OpenVEX statements are published.Public
REJECTEDThe report is invalid, out of scope, or a duplicate.Submitter and triage team
FromToRequired scopeCondition
SUBMITTEDVERIFIEDadvisory:verifySubmitted SBOM digest and signature are valid.
SUBMITTEDREJECTEDadvisory:verifyA rejection reason is provided.
VERIFIEDEMBARGOEDadvisory:embargoAn embargo end date and coordination group are set.
EMBARGOEDDISCLOSEDadvisory:discloseThe embargo end date has passed, or the coordinator records an early-disclosure reason.

DISCLOSED and REJECTED are final states. The API rejects any transition not listed in this table with 422 Unprocessable Content. See Errors.