Starting point

A vulnerability inbox turned into a working starting point for PSIRT and SBOM.

We establish how to receive vulnerability reports, which components affect you and who owns what, before the process becomes more mature.

Discuss the PSIRT/SBOM scope See a sample report

01 Fit

When this service fits

When vulnerability reports already reach you (by inbox, address or form) but there is no agreed way of handling them. It is a working starting point for device and software manufacturers, not a finished, mature PSIRT.

02 Scope

What we review

  • How reports are received: a coordinated vulnerability disclosure (CVD) policy, a security.txt file and a contact channel.
  • Report triage and an advisory template for customers.
  • The software bill of materials (SBOM) as the basis for judging what actually affects you.
  • The update and patch distribution process.
  • A CRA art. 14 runbook: who reports an actively exploited vulnerability, and how, to the coordinating CSIRT and to ENISA.
  • A tabletop dry run: what we do after a report of an actively exploited vulnerability.

03 Result

What decision the result supports

It leaves you with an agreed direction for reports, components and ownership, without pretending the process is mature on day one.

04 Inputs

What to prepare

  • How reports are currently received, if at all (inbox, address, form).
  • A list of products and components, or an existing SBOM.
  • The people responsible for the product, patches and customer communication.

05 Terms

How scope and quotation are set

Scope and quotation depend on the number of products, the material available and the conversations required. We establish both after a short scoping call.

06 Limits

What this service does not replace

We set up the vulnerability handling process, but we do not guarantee that the product is free of vulnerabilities. It is a starting point, not a mature, fully staffed PSIRT, nor a substitute for ongoing security work. The manufacturer remains responsible for legally required reports and for the product itself.

07 Process

Signal → review → evidence → decision

Signal

Where does the vulnerability report come from?

Review

Does it affect our product or a component?

Evidence

What can we confirm and show customers?

Decision

How and to whom do we report, and what do we fix?

08 Questions

Questions before starting

  • Is this a finished PSIRT? No. It is a working starting point that can then be developed and maintained.
  • Why do we need an SBOM? Without a component list it is hard to judge which reports actually affect you.
  • Does it connect with CRA Snapshot? Yes; it is the natural next step after CRA Snapshot.

09 Contact

Discuss the PSIRT/SBOM scope

We begin with a short description of the product and how reports reach you today.

Discuss your product

Source: CISA SBOM. Editorial review: CZ Cybersecurity sp. z o.o. Content reviewed: 21 July 2026.