Brief comms on three things: what open source components are, why one flaw can touch many products, and what is confirmed right now. Give them approved wording and a named technical contact. They do not need the exploit details. They need to avoid saying anything that later turns out to be false.
The background in plain language
Most modern software is built from many reusable parts, many of them open source. CISA describes an SBOM as a nested inventory, a list of ingredients that make up software components (CISA). Comms can use that picture: software is assembled from ingredients, and when one ingredient is found to be faulty, every product using it may be affected.
This explains why a vulnerability in a small library can make headlines. It is not necessarily a sign that a company was careless. It is a shared ingredient.
What comms should ask security for
| Ask | Why |
|---|---|
| Current status in one sentence | The core of any statement |
| Time of last check | So the statement is dated |
| Whether customers need to act | The first question journalists and customers ask |
| What is confirmed and what is unknown | Prevents overclaiming |
| Approved spokesperson | Keeps technical answers accurate |
Words to avoid
- "Secure" or "safe" as absolute claims.
- "No evidence of exploitation" without saying what was checked and over what period.
- "Isolated incident" unless security and legal have confirmed it.
- Anything about attackers' identity or intent.
- Any statement that a compliance report or certification covers the event.
Never describe an audit as complete unless it is, and never use certification language for something that is an attestation or a target.
A holding statement outline
We are aware of the reported vulnerability in [component]. Our security team is assessing whether it affects [product]. As of [time], our status is [status]. We will update [place] by [time]. Customers with questions can contact [channel].
Fill in only what is confirmed. If the status is under investigation, write that.
Preparing before it happens
- Agree who approves external statements and how fast.
- Keep a template with blanks, as above.
- Run a short drill once a year: a made-up headline, a clock, a statement drafted.
- Make sure comms has the shared status document and knows to quote it, not paraphrase.
During the event
Comms should join the update cadence rather than ask separately. One shared source of truth prevents contradictions between a press line and a customer note. If a journalist asks something outside the approved wording, the answer is "we will come back to you," followed by a real follow-up.
After the event
Record what questions came in. Those become the FAQ for next time.
Try it yourself
Click through it at your own pace, or open it full screen. Click through the inventory to see how one shared component appears in several places. That is the picture to give comms.
Where Safeguard fits
Safeguard's SBOMs and dependency scanning give the status line a factual basis, and the free scan at gold.safeguard.sh/scan shows what a project contains.
Quick check
Should comms say we are not affected?
Only after security confirms it and approves the wording, with a date.
Do comms need technical detail?
Enough to explain the ingredient idea and the status. The rest stays with the technical contact.
Sources
Last reviewed: 19 October 2026.
