A good internal notice states the affected package and versions, tells engineers what to stop doing, what to check on their own machines, and who to contact, in under 200 words. It carries no speculation and no blame. Send it before you finish investigating, then update it.
Why a template helps
In the first hour, engineers hear about a compromise from social media and start different fixes. A single message from the incident lead removes guesswork and prevents well meant actions that destroy evidence or spread the problem.
The template
Subject: Security notice, compromised package NAME, action needed
- What happened: package NAME versions X to Y were published with malicious code between TIME and TIME. Source: the registry advisory or maintainer notice.
- What to stop: do not run install, update or build commands that could fetch these versions. Do not merge dependency update pull requests until we confirm.
- What to check: run the check command or search shared by security for these versions on your machine and branches. Reply in the incident channel with found or not found.
- What not to do: do not delete caches, logs or node_modules yet. Security needs them.
- If you find it: stop, do not clean up, tell the incident lead. Disconnect from the network if you suspect it ran.
- Next update: we will post again by TIME.
- Contact: NAME and channel.
Tips for writing it
- Use exact versions and times, copied from a source.
- Say what is known and what is not. Use the words we do not yet know whether it ran in our environment when that is true.
- Keep one channel as the source of truth and pin the notice.
- Assign one communicator. See incident roles for a small team.
- Schedule the next update even if there is nothing new. Silence reads as inaction.
Customer messages are separate
Keep this notice internal. Customer messages need legal review and different detail. For wording, see status page update wording.
A filled in example
Subject: Security notice, compromised package example-lib, action needed. Body: versions 2.4.1 and 2.4.2 of example-lib were published with malicious code between two stated times. Do not install or update it. Search your branches for those versions and reply found or not found in the incident channel. Do not delete caches or logs. If you find it, stop and message the incident lead. We will update at the time stated. This is a made up package name, used only to show length and tone.
Quick check
Should the notice include the attacker's likely identity?
No. Attribution is speculation early on and does not change what engineers must do.
How often should we update it?
At the time you promised, even if only to say no change. Hourly in the first hours is common.
Safeguard's SBOM and dependency scanning can help engineers check quickly which projects carry an affected package. A free scan is at gold.safeguard.sh/scan.
Last reviewed: 19 October 2026.
