Block builds on yanked or retracted versions, because their authors say not to use them. Warn on deprecated versions and archived projects, and plan a replacement. The flags differ by ecosystem, and each one is a signal the maintainer or registry chose to send, which makes it more reliable than guesswork.
What each flag means
| Flag | Ecosystem | What the documentation says |
|---|---|---|
| Yank | Cargo | Removes a version from the index. No data is deleted and the crate stays downloadable. New projects without a lockfile will not use it |
| Retract | Go modules | A version or range should not be depended upon, for example when published prematurely or a severe problem was found. Versions remain available |
| Deprecate | npm | Prints a message on install. The message can say anything, such as pointing to a supported alternative |
| Deprecated comment | Go modules | A comment in go.mod marks the module as deprecated, and go list can surface it |
| Archived | Python packaging | The project does not expect updates. The index must not accept new uploads and installers may warn |
| Quarantined | Python packaging | The project is considered generally unsafe, for example due to malware |
The Cargo book describes yanking as a way to stop new dependencies on a version while builds that already have a lockfile keep working.
A policy that matches the intent
- Fail the build on a yanked version, a retracted version, or a quarantined project. The signal says do not use it, and fixing it usually means a version bump.
- Warn on a deprecated version, and open a ticket with an owner and a date. Read the message, since it often names the replacement.
- Warn on an archived project and treat it as end of life. Plan to replace or fork it.
- Re-evaluate when the replacement exists, not only when something breaks.
Note one nuance. A yanked version still installs from a lockfile in Cargo, so a policy that only trusts the resolver will miss it. A scanner or a check that reads registry metadata is needed.
Where the signals come from
Registry flags are metadata. The deps.dev API exposes isDeprecated and deprecatedReason for package versions across supported systems. For Go, go list with the update flag reports deprecated modules. In Cargo, the yank status appears in the index. Choose the source that your build can query without extra credentials.
Why not block on every flag
A deprecated package may be fine for a while, and an immediate failure creates pressure to silence the check. The aim is to make unsafe states loud and uncomfortable states visible. Reserve hard failures for flags that mean do not use.
Try it yourself
Click through it at your own pace, or open it full screen. See how a finding with a ready upgrade is presented, which is the shape of a good response to a yank or retract.
Where Safeguard fits
Safeguard provides SBOM and dependency scanning, policies and gates, and autonomous remediation with fix PRs, which is off by default and set per category. A free scan is at gold.safeguard.sh/scan.
Quick check
Does yanking delete a package?
In Cargo it does not delete data. It stops new projects without a lockfile from picking that version.
Is deprecated the same as vulnerable?
No. Deprecated is the maintainer's message. A vulnerability is a separate record. Check both.
Sources
- The Cargo Book: cargo yank
- Go Modules Reference
- npm Docs: Deprecating and undeprecating packages or package versions
- Python Packaging User Guide: Project status markers
- deps.dev API v3 documentation
Last reviewed: 19 October 2026.
