A package you depend on was compromised. Within a few hours your customers will ask whether they are affected, and the quality of your answer determines whether this costs you a week or a renewal.
Most teams handle the technical side competently and the communication badly, because the communication has to happen before the investigation is finished. This post is what to say at each stage, what not to say, and how to prepare the parts you can prepare in advance. For whoever owns customer trust at a software vendor.
The clock starts before you know anything
The pattern that damages vendors is silence followed by a detailed statement four days later. By then customers have asked on a public channel, got no reply, and formed a view.
The first message should go out within hours, and it does not require knowing whether you are affected. It requires knowing that you are looking.
We are aware of the compromise of [package] disclosed on [date]. We are assessing whether any Safeguard service is affected and will post an update by [specific time], whether or not we have concluded.
Three things make that work: it names the incident so customers know you are tracking the right one, it commits to a next update at a specific time, and it does not speculate. The commitment is the important part, because it converts an open-ended worry into a wait.
Then meet that time. An update saying "still investigating, next update at X" is a good update. A missed commitment is worse than not having made one.
Establish scope in this order
The question is not whether the package is in your dependency tree. It is whether the malicious version ever reached anything you run or ship.
- Which versions are malicious, precisely. Advisories often name a range that later narrows.
- Did you ever resolve one of those versions? Your lockfiles at the time answer this, and this is where a lockfile stops being a build convenience and becomes an incident artefact. If versions float, your answer is "possibly", which is a much worse position.
- Did it reach a build? A malicious version present in a lockfile on a branch that never shipped is a different finding from one in a release.
- Did it reach a customer? Shipped artifact, or a service you operate on their behalf.
- What could it do? Credential theft, a backdoor, cryptomining. This determines the remediation, and for credential theft the answer is to rotate regardless of whether you find evidence of use.
Steps 2 and 3 are where teams lose days, and they are answerable in minutes if you keep historical lockfiles and build SBOMs per release. That is the argument for generating an SBOM per artifact, made concrete: during an incident it is the difference between a query and an archaeology project.
What the follow-up says
Once you know, be specific. Vague reassurance reads as evasion, and security teams are trained to notice it.
If you were not affected, say why, with the mechanism: the version range, the dates, what you checked. "We never resolved an affected version; our lockfiles pinned 4.17.20 throughout the window, and the malicious releases were 4.17.22 and 4.17.23." A customer's security team can act on that. They cannot act on "we have determined we are not impacted."
If you were affected, state what was exposed, what you have done, and what they need to do. The last part is the one vendors omit and the one that actually matters to the reader. If they need to rotate an API key, lead with that.
If you do not know yet, say which specific question is open and when you expect to close it.
What not to say
- Do not claim more certainty than you have. Every overstatement gets revisited if the picture changes, and a corrected statement costs more trust than an uncertain one would have.
- Do not blame the maintainer. It reads badly, and your customers' interest is in your response, not in fault.
- Do not quietly fix and say nothing. If a customer later finds the affected version in an artifact you shipped, the absence of a notification is the incident, not the dependency.
- Do not send it only to whoever emailed. Others are wondering and have not asked.
- Do not put remediation advice behind a login. During an incident, friction on the mitigation is a real cost.
Prepare the parts you can
Almost all of the pressure comes from assembling things you could have had ready.
- A status page or advisory location, existing and known, so nobody is deciding where to post while the clock runs.
- A contact list of customers who want security notifications, maintained, because building one during an incident means you will miss someone.
- Historical lockfiles and per-release SBOMs, which turn the scope question into a query.
- A holding statement template, so the first message is an edit rather than a draft.
- A named owner for the decision to publish. Incidents stall on approval more often than on analysis.
None of this is expensive. All of it is nearly impossible to create in the two hours after an advisory lands.
The concession
There is real tension between speed and accuracy, and the advice to communicate early does have a cost: an early statement is more likely to need correction, and every correction is a small credibility charge.
The way through is to separate what you know from what you are doing. "We are investigating X, we have not yet determined Y, next update at Z" is fast and cannot be wrong, because it makes no claim about the outcome. Reserve definite statements for things you have actually verified, and the corrections mostly stop happening.
The implication
Your customers are not really evaluating whether you were affected. Most vendors are, eventually, by something. They are evaluating whether you find out quickly, tell them honestly, and know what you ship.
That judgement gets made in the first day, largely on the basis of whether you could answer "were you running the bad version" without a week of investigation. Which makes the preparation, the lockfiles and the SBOMs and the contact list, a communication investment rather than an engineering one.
