Protection checks PyPI, npm, and Maven package versions for known vulnerabilities, malware, suspicious code, unsafe archive content, and other risks. Checks run in the background and never execute package code.
Each package format in a repository has its own Protection policy. Every policy answers three questions:
Every repository starts with Balanced protection for PyPI, npm, and Maven. Policies act automatically; you can still quarantine or release any version, and allow findings that don’t apply to you. Known malware is always blocked, whatever the policy.
Container and Helm content does not currently have Protection assessments.
Ravenstash gives every finding that can affect a policy one risk level, from lowest to highest:
| Risk level | Meaning |
|---|---|
| Low, Medium, High, Critical | Vulnerability severity. |
| Known exploited | Vulnerabilities attackers are known to exploit. |
| Suspected malicious | Strong signs that a package was built to cause harm. |
A policy places two thresholds on this scale. Each threshold is a risk level or Never. A version reaches a threshold when its highest counted finding is at or above that level. The scale is cumulative: quarantining from Critical also quarantines versions with known exploited or suspected malicious findings.
The thresholds divide the scale into zones:
| Zone | What happens |
|---|---|
| Reported | Shown as findings. Availability doesn’t change. |
| Review | Flagged for review. Versions stay available. |
| Quarantine | Quarantined automatically. Versions can’t be installed until released. |
| Always blocked | Known malware is blocked in every repository and can’t be allowed. |
Known malware sits beyond the scale. It is not a threshold, and no policy, release, or allowed finding changes it.
Every finding appears in the version’s details, but only some findings count toward the thresholds. These never flag or quarantine a version:
Findings in optional dependencies count only when the policy includes optional dependencies. Suspicious install scripts, exposed secrets, and suspicious code patterns count only when the policy includes suspicious code signals.
A policy uses one of four presets or a Custom profile. A preset fixes every setting: both thresholds, what happens while checks run and when they fail, and which extra checks run. Choose Custom to pick each setting yourself.
| Setting | Observe | Balanced protection | Strong protection | Strict intake |
|---|---|---|---|---|
| Review from | High | High | Medium | Low |
| Quarantine from | Never | Critical | High | Medium |
| While checking | Available | Available | Available | Held |
| If checks fail | Available with a warning | Available with a warning | Quarantined | Quarantined |
| Deeper dependency analysis | Not included | Not included | Included | Included |
| Optional dependencies | Not included | Not included | Included | Included |
| Suspicious code signals | Not included | Not included | Not included | Included |
Each preset describes itself from its thresholds and behavior:
The settings mean:
| Setting | Meaning |
|---|---|
| While checking: Available | New versions can be installed while checks run. |
| While checking: Held | New versions can’t be installed until checks finish. |
| If checks fail: Available with a warning | Versions stay available and show why checks didn’t finish. |
| If checks fail: Quarantined | Versions are quarantined until a check succeeds. |
| Deeper dependency analysis | Resolves dependencies for supported runtimes to find risks they bring in. |
| Optional dependencies | Also checks optional dependencies. |
| Suspicious code signals | Also acts on suspicious install scripts, secrets, and code patterns. |
For PyPI, deeper dependency analysis considers supported CPython versions from Python 3.10 onward. Ravenstash uses the package’s declared Python requirement to choose the applicable versions. For example, a package that declares Python 3.10 and 3.11 is checked for those versions, while a package that requires Python 3.12 or newer is checked for the supported versions in that range.
A package that supports only Python versions older than 3.10 still receives the other Protection checks. Deeper dependency analysis is simply not applicable. If the package’s Python requirement can’t be understood, the check is shown as incomplete instead of treating the package as incompatible.
Choose Custom when no preset fits. Custom starts from the preset you had selected, and you choose:
The thresholds follow these rules:
A Custom profile is described from its settings the same way as a preset, for example “Flags Medium and above for review. Quarantines High and above. Holds new versions until checks finish.”
Current policy shows the preset or Custom, with the Recommended badge for Balanced protection, when the policy started to apply and its revision, the risk scale with both thresholds, and three summaries: Flag for review, Quarantine automatically, and While checking / If checks fail. It also shows which extra checks are included. Anyone who can open the repository’s Protection pages can view it.
Repository Maintainers and Admins can change the policy under Change policy:
A saved policy applies to package versions added from then on. Existing versions keep their current state unless you apply the policy to them. Saving never rescans, quarantines, or releases a version that is already in the repository.
A policy also applies immediately to versions that this repository serves from attached private repositories. Those versions are stored in their source repository, so this repository’s current policy decides whether it delivers them each time they are requested. See Block versions from an attached private repository.
While existing versions still use an earlier policy, Existing versions on the policy page shows how many and offers Review impact on existing versions. This is an optional, temporary review. Ravenstash runs any extra checks needed for an accurate comparison, and those checks never change the current state of an existing version. The review keeps running if you leave the page, and its progress and results appear when you return.
The review counts the versions that would be Quarantined, Held until checked, Made available, Flagged, or No longer flagged, and lists only those versions. Each row shows the version’s current state and its future state under the saved policy, for example Available → Quarantined, and why: the findings with the threshold each one reached, or the checks that couldn’t finish and what the saved policy does when checks fail.
Lowering protection matters too: a version that an earlier policy quarantined can become available. When nothing would change now, the review says so. Applying the policy still moves existing versions to it, so it decides what happens when they are checked again, for example when a new vulnerability is published.
The review reuses what Ravenstash already knows about each version together with current security information. A version with no matching finding is not proof that a new check would find nothing.
After a completed review, a repository Maintainer or Admin can choose Apply to existing versions (or Use this policy for existing versions when nothing would change now). Ravenstash shows the changes and notes that cached downloads of quarantined versions are removed before asking for confirmation. Applying uses the review’s results and checks; it doesn’t rescan. A progress bar shows the versions processed, and the page then shows how many versions were changed. If findings, allowed findings, or settings change before applying starts, Ravenstash doesn’t apply the outdated review and offers Review impact again. Applying never overrides a version you quarantined or released yourself, and allowed findings still don’t count.
With While checking: Available, a new version can be installed while its checks run. Its status shows Checking.
With While checking: Held (Strict intake), a new version can’t be installed until its checks finish. It appears in the Quarantine view as Held while checking. Holding is not quarantine: the version becomes available as soon as its checks finish without reaching the quarantine threshold.
Thresholds apply to every finding Ravenstash already has for a version, even while a new check is running or when a check didn’t finish.
A check can end without complete results. Ravenstash shows one of these statuses:
| Status | What it means |
|---|---|
| Check incomplete | “Some checks couldn’t finish”, followed by the checks involved: Component inventory, Declared dependencies, Bundled dependency evidence, Dependency resolution, or Code and malware scanning. |
| Check delayed | “Checking was interrupted. Ravenstash retries automatically.” |
| Couldn’t check package | “This package’s files couldn’t be read, so its contents weren’t checked.” or “This package is too large or complex to check completely.” |
Ravenstash re-checks automatically where another attempt can help:
When an automatic re-check is scheduled, the version’s details show when the next retry will happen. You can select Rescan at any time to request another check.
The policy’s If checks fail setting applies to every status above:
Thresholds still apply first. For example, if an incomplete check found a Critical vulnerability, Balanced protection quarantines the version.
To respond to a check that didn’t finish:
| Status | Meaning |
|---|---|
| Checking | Package checks are queued, running, or being refreshed. |
| No known issues | No applicable known issue is currently reported for the version. This is not a guarantee that the package is risk-free. |
| Has findings | Findings exist, but none reached the policy’s review threshold. |
| Flagged | A finding reached the review threshold, or the package couldn’t be checked. The version stays available. |
| Check incomplete | Some checks couldn’t finish. |
| Check delayed | Checking was interrupted, and Ravenstash retries automatically. |
| Couldn’t check package | The package couldn’t be read, or it is too large or complex to check completely. |
| Not checked | No completed result is available yet. |
| Known malware detected | Ravenstash matched the version to trusted malware information and applied a mandatory safety block. |
A version’s details state which threshold each finding reached, for example Reached the review threshold (High) or Reached the quarantine threshold (Critical). Findings below the review threshold remain visible without changing the version’s status.
Risk level and the flag answer different questions. A finding flags a version only when its level reaches the policy’s review threshold, while a package that couldn’t be checked is flagged without having any finding.
| Availability | Meaning |
|---|---|
| Available | Installers can download the version from this repository. |
| Checking · Blocked while checking | Strict intake is holding a new version until its checks finish. This is not quarantine. |
| Quarantined | The version is contained in its own repository. Downloads are blocked everywhere it is used. |
| Changing availability | A quarantine or release is still completing. Downloads remain blocked until it finishes. |
| Blocked in this repository | A repository Maintainer or Admin blocked a version that this repository receives from an attached private repository. |
| Blocked by this repository | This repository’s Protection policy blocks a version it receives from an attached private repository. |
| Mandatory safety block | The version matches trusted malware information. No policy or action can make it downloadable. |
Protection → Quarantine lists every version that installers can’t currently download from this repository, with its reason: Reached the quarantine threshold (with the level), Held while checking, Checks failed, Couldn’t check package, a manual quarantine, or a block from or on an attached private repository.
A quarantined, held, or blocked version is never also flagged.
These static examples use sample package names and evidence. They show how status, severity, thresholds, availability, and flags can appear together. The action labels illustrate controls in the app; they are not interactive here.
Illustrative assessment
4.8.0According to your policy, this package CAN still be downloaded.
Affects request-helper 2.1.0 · Fixed in 2.1.1
Reached the review threshold (High)
Illustrative assessment
1.9.2This package is quarantined and CANNOT be downloaded.
Affects archive-reader 5.0.1 · Fixed in 5.0.3
Reached the quarantine threshold (Critical)
Illustrative assessment
2.3.1According to your policy, this package CAN still be downloaded.
Affects response-parser 3.4.0 · Fixed in 3.4.2
Allowed · This package
Not reachable: the parser only reads trusted internal responses.
Illustrative assessment
1.7.0This package is quarantined and CANNOT be downloaded.
Strong protection quarantines versions whose checks fail.
Open a package version and read the finding summary and Technical evidence. Depending on the finding, Ravenstash can show the affected component, detected version, fixed versions, location, confidence, whether the vulnerability is known to be exploited, and which threshold the finding reached.
When a version is Flagged:
A flag needs no other decision. It clears when the finding is allowed, the version is quarantined or released, or a new check no longer reports the finding.
A release accepts the findings the version has at that moment. They stop counting toward the thresholds, and checks that are still running or didn’t finish no longer hold or quarantine the version. A new finding, or an accepted finding whose risk level rises, counts again: if it reaches the quarantine threshold, the version is quarantined again with that reason. Quarantining the version yourself ends the release. Rescans, new security information, and applying a policy to existing versions keep it.
Known malware can’t be released.
Select Allow on a finding in Technical evidence when it doesn’t apply to you, for example because the vulnerable code is never reached. Choose where it is allowed:
You can add a note and an expiry. An allowed finding stays visible, shows Allowed with its scope, and no longer counts toward the review or quarantine threshold. It counts again if its risk level rises, when the allowance expires, or when you remove it. Ravenstash checks the affected versions again right away, so allowing a finding can make a quarantined version available and removing an allowance can quarantine it again.
Protection → Allowed findings lists the allowed findings of each package format with their scope, how many versions stored in this repository they currently cover, the risk level when allowed, and their note and expiry. Repository Maintainers and Admins can widen a finding’s scope to the package or the whole format, or remove it.
Known malware can’t be allowed.
A version that this repository receives from a directly attached private repository is stored in that source repository, so it cannot be quarantined here. Instead, its Protection panel offers Block and Unblock in the same places as Quarantine and Release. Its findings come from the source repository.
By default, findings allowed in the source repository don’t apply here. Turn on Use allowed findings from attached private repositories on this repository’s Allowed findings page to apply them too.
This repository’s current policy applies to these versions immediately. When you save a new policy, versions from attached private repositories are checked against it right away, unlike versions stored in this repository.
This repository flags these versions by its own policy and allowed findings. It doesn’t run its own checks on them. If this repository’s policy includes checks that the source repository’s policy doesn’t run, such as Deeper dependency analysis, the version shows Checks not run with the checks involved, and this repository’s If checks fail setting decides whether it is delivered. To include those checks, use the same extra checks in the source repository’s policy.
Blocked versions appear in this repository’s Quarantine view. Versions from mirrors are not affected by these controls.
From a package version’s Protection assessment, you can:
Protection is one input to a software-supply-chain decision. Continue to use the code review, signing, provenance, dependency update, and release controls required by your organization.