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

02 Scope

What we review

What a PSIRT is, and what an SBOM is

A PSIRT (Product Security Incident Response Team) is the function at a manufacturer that receives vulnerability reports about its own products, triages them, and carries them through to a fix and a notice. It is not the same as a SOC or a CSIRT: those protect the organisation's own infrastructure, while a PSIRT answers for what the company sold to someone else. Two standards describe the practice: ISO/IEC 29147 (receiving and disclosing reports) and ISO/IEC 30111 (handling a report inside the organisation).

An SBOM (Software Bill of Materials) is a machine-readable inventory of the components a product is built from: names, versions and the relationships between them. It answers the question "does this affect us?", asked whenever a vulnerability is disclosed in somebody else's library. Two formats are standard in practice: SPDX and CycloneDX. Annex I Part II of the CRA requires a manufacturer to identify and document components, including drawing up an SBOM.

CVD (Coordinated Vulnerability Disclosure) is the agreed process by which a reporter and a manufacturer settle what is disclosed and when. Without one, a report either disappears or goes straight to publication.

Standard names are given as reference points; their text is under copyright and is not reproduced here. The SBOM requirement: Regulation (EU) 2024/2847, Annex I Part II. Material on the formats: CISA SBOM.

What the review covers

• 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.

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.

06 Limits

What falls outside the scope

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.

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.