> For the complete documentation index, see [llms.txt](https://docs.arnica.io/arnica-documentation/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.arnica.io/arnica-documentation/code-risks/3rd-party-package-reputation.md).

# 3rd Party Package Reputation

## Overview

Arnica evaluates the reputation of open source packages used across your codebase. When a dependency shows signs of being unmaintained, obscure, or lacking community trust, Arnica flags it as a low-reputation finding.

Low-reputation packages are a common supply chain risk. They are more likely to carry unpatched vulnerabilities, receive no security updates, and attract malicious actors looking to exploit abandoned or low-visibility packages. Catching them early reduces your exposure before they become a problem.

## How Arnica evaluates reputation

Each package is scored across seven factors. Arnica weighs these signals together and flags packages where the combined picture suggests risk.

* **Number of releases** — A low release count suggests the package is either early-stage or stagnant. Packages with a consistent release history are more likely to be actively developed and responsive to security issues.
* **Number of stars** — Stars are a proxy for community trust. A low star count may indicate the package is not widely known or adopted, which reduces confidence in its quality and long-term maintenance.
* **Number of dependents (last 3 versions)** — How many other packages rely on this one. Low dependents across recent versions suggests limited ecosystem trust, and may indicate compatibility or reliability concerns.
* **OpenSSF Scorecard overall reputation** — The [OpenSSF Scorecard](https://securityscorecards.dev/) measures how well an open source project follows security best practices, including code review, vulnerability management, and security policies. A low score is a direct signal of security risk.
* **Days since first publish** — Newer packages have less real-world testing behind them. An established package with years of production usage is generally more stable and better understood.
* **Days since last publish** — A long gap since the last update often means the package is abandoned. Unmaintained packages accumulate unresolved vulnerabilities and fall out of step with ecosystem changes.
* **Number of downloads last week** — Download volume reflects active usage. A low download count can signal that the broader community has moved away from the package, or that it never gained meaningful adoption.

### Example

<figure><img src="https://4035514934-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FMxc1Ek3qoIZi5t2Sx7do%2Fuploads%2Fgit-blob-214241d5238ff4e757a7fe72dcc0291917512662%2Fimage%20(160).png?alt=media" alt="mocha-phantomjs-istanbul@0.0.2 reputation finding showing radar chart and factor table"><figcaption><p>mocha-phantomjs-istanbul@0.0.2 — a package with High impact across nearly all reputation factors</p></figcaption></figure>

## Reading a finding

Each low-reputation finding includes:

* **Radar chart** — a visual snapshot of the package across all seven factors, making it easy to see at a glance where it falls short.
* **Factor table** — lists each factor with an Impact rating (High, Medium, or Info) and its current value. Factors marked High carry the most weight in the reputation assessment.
* **File and commit context** — shows exactly where in your codebase the package is referenced, including the file, line, commit, author, and pusher.

## What to do

If you find a low-reputation package in your codebase, evaluate whether it can be replaced with a better-maintained alternative.

See [How to Find Alternative Packages](/arnica-documentation/code-risks/3rd-party-package-reputation/how-to-find-alternative-packages.md) for guidance by package manager (NPM, NuGet, PyPI, and more).

## Package Cooldown

Package Cooldown gives your team time to evaluate newly published package versions before adopting them. When enabled, Arnica reports versions inside the configured waiting period as **Critical** package reputation findings, even when the package has a strong reputation or no known vulnerabilities.

{% hint style="info" %}
The Critical severity indicates that the version is too new for your policy. It does not mean Arnica has confirmed a vulnerability or malicious behavior.
{% endhint %}

### How it works

Arnica compares the publication time of the package version used by your project with the configured cooldown period. The window starts when that version was published, not when you added it to your project or opened a pull request. Each day is a full 24-hour period.

For example, with a **7-day** cooldown, a version published on September 1 at 10:00 UTC remains inside the window until September 8 at 10:00 UTC. Rerun the scan after that time to evaluate it without the cooldown override.

Cooldown applies during package reputation scans, including pull request, push, and routine scans. It follows your organization's existing reputation scanning scope: if only direct dependencies are scanned for reputation, cooldown findings are limited to those dependencies. Transitive dependencies are included when reputation scanning includes them. Operating system packages are excluded.

Cooldown findings use the existing **Reputation** finding type. Arnica still calculates the package's underlying reputation, but applies Critical severity while the cooldown is active. Existing policy rules evaluate that Critical severity.

### Enable Package Cooldown

1. Open the [Policies page](https://app.arnica.io/#/admin/policy-v2) for the organization connected to the repository you want to scan.
2. Expand **Code Risk**, then open **Configuration → Reputation**.
3. Turn on **Enforce Package Cooldown**.
4. Set **Cooldown period (days)** to a whole number from **1 to 14**. The default period is **1 day**; enforcement is off by default.
5. Select **Save** and confirm the policy change. Use **Undo** to discard unsaved changes.

<figure><img src="https://4035514934-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FMxc1Ek3qoIZi5t2Sx7do%2Fuploads%2Fgit-blob-3cc9ec8a19de43b9a8b5793813b00175a784be58%2Fpackage-cooldown-policy-settings.png?alt=media" alt="Code Risk configuration with Enforce Package Cooldown enabled and Cooldown period set to 14 days"><figcaption><p>Package Cooldown enabled with a 14-day waiting period.</p></figcaption></figure>

If the Reputation section or cooldown setting is unavailable, contact Arnica support to check availability for your organization.

### Configure pull request enforcement

Enabling cooldown changes finding severity. PR comments and failed status checks depend on your enabled [Code Risk policy rules](/arnica-documentation/code-risks/code-risk-policy-settings.md).

To report cooldown findings and fail the PR status check, configure a rule with:

* **Trigger:** Code risk detected on pull request.
* **Conditions:** A severity threshold that includes Critical. If you filter by finding type, include **Reputation**.
* **Actions:** **Comment on pull request** and **Fail status check**.

An existing rule that matches Critical reputation findings can handle cooldown findings without a separate rule. These conditions also match other Critical reputation findings.

Only the first matching rule runs, so check that an earlier rule does not match the finding before your enforcement rule. To prevent merging, also require the Arnica status check on the target branch. In the policy, use **view unenforced branches** to configure enforcement for the relevant repositories and branches.

### Review a cooldown finding

Open the reputation finding to review the package version and its reputation factors. The **Package version published** row shows a Critical impact while cooldown is active, and the reputation chart includes **Package cooldown**.

<figure><img src="https://4035514934-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FMxc1Ek3qoIZi5t2Sx7do%2Fuploads%2Fgit-blob-e3ec18b38131282d650720697a3f1e94403820e3%2Fpackage-cooldown-reputation-finding.png?alt=media" alt="Reputation details for zod@4.6.5 showing Package cooldown in the chart and a Critical impact for Package version published 3 days ago"><figcaption><p>In this example, zod@4.6.5 was published 3 days before the scan, inside the configured 14-day cooldown. Its publication age has a Critical impact even though its other reputation factors are Info.</p></figcaption></figure>

When your policy posts a PR comment, it explains:

* Which package version is inside the Package Cooldown policy window.
* The publication date, configured duration, and expiration date.
* How to rerun Arnica after the window expires.

PR comments show dates. The cooldown itself uses the publication timestamp, so reaching the expiration date at midnight does not necessarily mean the full waiting period has elapsed.

### Resolve a cooldown finding

After the window expires, rerun the scan. For a pull request, add this comment:

```
[arnica] rerun
```

On the next scan, Arnica removes the cooldown override and evaluates the package's underlying reputation:

* If the package still qualifies for a reputation finding, the finding remains at its calculated reputation severity.
* If cooldown was the only reason for the finding, Arnica resolves it automatically.

{% hint style="info" %}
Time passing alone does not refresh a finding or a PR status check. Other findings can also keep a status check failing after cooldown expires.
{% endhint %}

If you need to proceed sooner, evaluate a version outside the cooldown window, or review the package and use your organization's [dismissal process](/arnica-documentation/code-risks/code-risk-policy-settings/dismissal-settings.md) when appropriate. An older version may still have vulnerabilities or other reputation risks.

### When publication metadata is unavailable

If the publication lookup fails, or a supported package's metadata lacks a valid publication date, Arnica reports a Critical reputation finding with **Publication metadata unavailable**. Arnica cannot calculate a cooldown expiration without a valid date.

Review the package version before using it. Rerun the scan to retry the lookup, or follow your organization's dismissal process after verifying the package is acceptable.

Unsupported ecosystems and packages not found by the metadata provider are skipped by cooldown enforcement. A package without a cooldown finding has not necessarily passed an age check.

### Change or disable cooldown

Return to **Code Risk → Configuration → Reputation**, change the duration or turn off **Enforce Package Cooldown**, then save. Subsequent reputation scans use the updated setting. Rerun affected PR scans to refresh their findings and status checks.

Disabling cooldown removes its severity override on the next scan. Package reputation evaluation continues, so findings caused by other reputation factors can remain.