Ask one question first: what went wrong, and where? A flaw in code you run is a vulnerability. Code that was intentionally harmful is a malicious release. A company that lost data or access is a vendor breach. Each calls for a different first move, so sort the headline before you act.
Why sorting comes first
Headlines blur these together. "Supply chain attack" can describe a poisoned package, a stolen signing key, or a hosting provider that lost customer data. The words feel the same. The work is not.
If you treat a vulnerability like a malicious release, you may rotate credentials for no reason. If you treat a malicious release like a vulnerability, you may wait for a patch that never comes. If you treat a vendor breach like a code problem, you will search your lockfiles and find nothing, while the real question, what data of yours the vendor held, goes unasked.
The three types
A vulnerability is a problem in code that could be exploited. GitHub's documentation describes it as a problem in a project's code that could damage confidentiality, integrity or availability, usually introduced by accident and fixed soon after discovery. A vulnerability advisory lists the affected version range and the earliest fixed version.
A malicious release is code designed to do harm. The same documentation says malware is intentionally designed to perform unwanted or harmful functions, and that malware alerts carry no fixed version, because there are no safe versions: the safe course is to stop using the package.
A vendor breach is an incident at a company you rely on, where its systems, data or credentials were accessed. Your code may be untouched. Your exposure runs through what you gave the vendor: data, tokens, access.
Decision table
| Signal in the headline | Likely type | First move |
|---|---|---|
| "Flaw", "bug", "CVE", "patch available" | Vulnerability | Check version, apply the fix, assess exploitability |
| "Malicious", "backdoored", "hijacked package", "published without authorization" | Malicious release | Find installs inside the window, pin back, rotate secrets that environment could read |
| "Breach", "unauthorized access to systems", "customer data" | Vendor breach | List what you share with the vendor, rotate shared credentials, read their notice |
| "Compromised build system", "stolen signing key" | Malicious release or vendor breach, depending on source | Read the primary notice for what was signed or shipped |
When the signals mix, look at what the primary source says was affected: your code, your data, or both.
Worked example 1: a vulnerability
A notice says a parsing library has a flaw that allows remote code execution through crafted input, fixed in 8.4.2. You run 8.4.0.
First move: check how you use the library. If it parses untrusted input, you have real exposure. Upgrade to the fixed version and check whether anything exploited it before you patched. If you only parse trusted internal files, the urgency is lower. Either way, the answer sits in a version bump and a usage check.
Worked example 2: a malicious release
A notice says versions 2.2.0 and 2.2.1 of a build helper were published by someone other than the maintainer and contain code that sends environment variables to an outside server.
There is no fixed version to move to. First move: find every build and machine that installed those versions in the window, pin to the last known good version, and treat any environment that ran it as exposed, so rotate the secrets it could read. The question is "did we run it", and the response is containment and rotation.
Worked example 3: a vendor breach
A hosted tool you use for logging says attackers accessed its systems and may have copied customer data. You have no dependency on its code, only a log shipping key and the logs you send.
Searching lockfiles tells you nothing. First move: list what you send, such as log content that might include tokens or personal data, rotate the shipping key, read the vendor's notice for what was accessed and when, and check your own obligations to notify anyone if regulated data was involved. Involve your privacy or legal contact for that last step.
Steps to sort a headline
- Find the primary source and read what exactly was affected.
- Decide: code flaw, harmful code, or company incident.
- Write the type at the top of the ticket.
- Pick the first move from the table.
- Revisit the type if new facts change it. Some incidents start as one and turn out to be another.
When the type changes mid-incident
Some stories start as one type and turn into another. A report of a strange package release may begin as "possible vulnerability" and become "malicious release" once someone reads the code. A vendor incident may begin as "outage" and later be described as a breach. Keep the type line in your ticket editable, and date every change. When the type changes, rerun the first move from the table, because the right response may be quite different.
Try it yourself
Click through it at your own pace, or open it full screen. Use it on the vulnerability case: work out whether a flaw in a library matters given how you actually use it.
Safeguard's reachability analysis and dependency scanning address the vulnerability case in particular, helping you see whether a flawed function is used. The malicious release and vendor breach cases rest more on your inventory and your own records.
Quick check
Why does a malicious release have no fixed version?
Because no release of that package can be trusted as the malicious code is the point. GitHub's docs say the safe course is to stop using it.
Can one incident be more than one type?
Yes. A stolen key might lead to a malicious release, and the company that lost the key had a breach. Treat each part with its own first move.
What if the source does not say which type it is?
Record that it is unclear, take cheap safe steps such as pinning, and recheck when the owner publishes more detail.
Sources
Last reviewed: 19 October 2026.
