Package Firewall policy

Package Firewall evaluates each request from a package manager client or a private package registry before download from a public registry. Use a policy to control which installations are blocked or allowed. For packages that fail the policy, you can block the download, allow it and record a warning, or remove only the unsafe versions so a safe version installs instead. Configure the Package Firewall policy to block a package installation, allow it and record a warning, or allow only the safe versions of a package.

• Block: Prevents the package installation and returns an error. Select this action when you want to ensure the package never reaches your environment.
• Warn: Allows the package installation and logs it as a warning event. Select this action when you want visibility without risking build interruptions.
• Allow safe versions only (curate): Removes the unsafe versions from the list of versions available to the package manager client, so it resolves and installs a safe version instead of failing. Developers get a working version without seeing a block. This action is available for the malware and minimum package age conditions. See Allow safe versions to learn more.

Package Firewall enforces these actions based on the conditions you configure in the policy.

• Exceptions: Specify packages to exclude from enforcement. When a package matches an exception, Package Firewall skips all checks and allows the installation. Exceptions override other conditions such as restricted licenses and minimum package age, making them useful for approved packages that must remain available for critical builds and package installation workflows. You can define exceptions for a single version, multiple versions, or a version range. For version ranges, the lower bound is inclusive and the upper bound is exclusive. If you do not configure version limits, the exception applies to every version of that package for the selected ecosystem. You can also use exceptions to allow a specific VS Code extension to install regardless of the policy. Exceptions apply only to the packages explicitly listed and do not cover transitive dependencies. If a transitive dependency is flagged, it is blocked even if the parent package has an exception. Add that package as a separate exception to allow its installation.
• Vulnerabilities: Set a CVSS severity threshold. Endor Labs uses CVSS 3.x by default and evaluates vulnerability severity using that version. You can change the CVSS version for your namespace in System Settings. If a package has a known vulnerability at or above this threshold, the configured policy action is applied.
• Restricted licenses: You can define a list of SPDX licenses that your organization considers restricted. If a package version matches one of these licenses, Endor Labs applies the configured policy action, helping enforce legal and open-source compliance at install time.
• Minimum package age: Set a minimum number of hours that must pass after a version is published before it is considered safe. If a version is newer than this threshold, Endor Labs applies the configured policy action, mitigating risk from newly released packages.

Endor Labs records every package installation request together with the action taken. See View Package Firewall logs to learn more.

​

Allow safe versions

When you set the malware or minimum package age action to Allow safe versions only (curate), Package Firewall filters the versions it returns so the package manager client can resolve from only safe versions. If no safe version is available, Package Firewall blocks the request.

1. When the package manager client requests a list of available versions, Package Firewall removes any versions flagged as malware or younger than the minimum package age, then returns only the remaining safe versions.
2. The package manager client resolves a version from the safe list using its own resolver, then requests it.
3. Package Firewall evaluates the selected version against any configured restricted license and vulnerability conditions. If the version matches one of those conditions, Package Firewall warns or blocks the installation according to the configured action.

The Package Firewall log records this event with the action Allowed safe versions and the reason Curated. Package Firewall does not test whether a remaining safe version is backward compatible with your application. Test the resolved version in your own environment before you rely on this action. This action applies only to the malware and minimum package age conditions. It does not apply to restricted license or vulnerability conditions, which Package Firewall always evaluates after the package manager client selects a version. This action is available for the npm, PyPI, RubyGems, and VS Code ecosystems. See Policy support by ecosystem for the conditions and actions available in each ecosystem. Package Firewall can filter the version list only when the package manager client requests a list of available versions rather than an exact version. Package Firewall blocks the request and logs the event with the action Blocked and the reason Curated if either of the following conditions is met:

• The installation requests an exact version, and that version is unsafe.
• All available versions are unsafe and Package Firewall has no safe version to return.

​

Action when a policy cannot be evaluated

You can configure what Package Firewall does if it fails to complete a policy check on a package. The check can fail if the malware feed, the policy service, the datastore, or the cache is unavailable, or if Package Firewall cannot fetch upstream registry metadata. Choose what Package Firewall does if the policy check fails:

• Block (Fail-close): Rejects the package at install or resolve time.
• Warn (Fail-open): Allows the package installation and records the event. This is the default behavior.

This action applies only when a policy check cannot complete. Packages that fail a policy check still follow the action set for that policy. A total outage that prevents Package Firewall from reading your policy settings blocks the package with an HTTP 502 error, whatever the action is set to, and Endor Labs records the event. If the policy check fails because of an authentication failure, Package Firewall rejects the request. If Package Firewall cannot find the package’s metadata in the upstream registry, it always allows the request, whatever the action is set to.

​

Configure the policy

You can configure the Package Firewall policy to block or warn installations based on malware detection, exceptions, vulnerabilities, restricted licenses, and minimum package age conditions. The Package Firewall evaluates each package against the policy in the following order: Exceptions → Malware → Vulnerability → Restricted License → Minimum Package Age. If a package is listed as an exception, all checks are skipped. If a check matches and the action is Warn, the event is logged and the evaluation continues. If the action is Block, the installation is blocked and all checks are skipped. When the malware or minimum package age action is set to allow safe versions only, Package Firewall filters the version list instead of blocking the request. See Allow safe versions to learn more. You can also set up notifications to receive Slack messages when the firewall blocks or warns on a package installation. See notifications to learn more. You require Admin role permissions to change the Package Firewall policy. See authorization roles to learn about the different roles Endor Labs offers. Configure the Package Firewall policy once, at your tenant’s root namespace, regardless of where the integration lives. The policy propagates to all child namespaces, but you cannot override it or set a separate policy for each namespace under the same tenant. Before configuring the policy, set up a Package Firewall integration in your namespace. See Package Firewall for setup instructions.

1. Select User menu > Policies & Rules from the left sidebar.
2. Select Package Firewall Policies.

​

Configure malware detection

Set the action the Package Firewall takes when it detects malware in a package.

1. Select Malware.
2. Choose Block, Warn, or Allow safe versions only (curate) if the package is flagged as malicious.
3. Click Save.

​

Set a minimum package age

Block or warn package installations when a version was published more recently than a threshold you define.

1. Select Minimum Package Age.
2. Enter the number of hours that must pass after a version is published before it can be installed in Minimum package age in hours.
3. Choose Block, Warn, or Allow safe versions only (curate) if the condition is met.
4. Click Save.

To see how Package Firewall determines a version’s age in each ecosystem, see How minimum package age is determined per ecosystem.

​

Restrict licenses

Define the SPDX licenses your organization considers restricted and how Package Firewall responds when a restricted license is detected. Restricted license enforcement does not apply to the Go and VS Code ecosystems. See Policy support by ecosystem for license detection limits in other ecosystems.

1. Select Restricted License.
2. Click Add Licenses.
3. Search for and select the licenses you want to restrict. You can search by the SPDX name or identifier of the license.
4. If you don’t find the licenses you are looking for, enter a comma separated list of licenses in Add custom licenses.
5. Click Add & select.
6. Click Save.
7. Choose to Block or Warn if the condition is met.
8. Click Save.

​

Set a vulnerability threshold

Block or warn package installations that have vulnerabilities at or above a CVSS severity threshold. Vulnerability enforcement does not apply to the VS Code ecosystem.

1. Select Vulnerability.
2. Choose Critical or High & Critical in Select CVSS severity.
3. Choose to Block or Warn if the condition is met. Choose Do nothing to skip the vulnerability check.
4. Click Save.

​

Set the action for packages that cannot be evaluated

Set the action Package Firewall takes if it cannot complete a policy check for a package. See Action when a policy cannot be evaluated to learn more.

1. Select Package not evaluated.
2. In Action when a policy cannot be evaluated, choose Block (Fail-close) or Warn (Fail-open).
3. Click Save.

​

Add exceptions

Add packages that bypass the Package Firewall entirely, skipping all malware, license, vulnerability, and minimum-age checks for those installations.

1. Select Exceptions.
2. Click Add package exceptions.
3. Choose the Ecosystem.
4. Enter the package name in Package name. For a VS Code extension, use its identifier in publisher.name form, such as ms-python.python, which appears as the unique identifier on the extension’s Marketplace page.
5. Optionally, turn on Specify versions and apply the exception to specific versions. If you leave this off, all versions of the package bypass the Package Firewall.
   • To exclude a specific version, choose Exact version and enter the version to exclude.
   • To exclude a range of package versions, choose Version range and enter the lower and upper bounds. The lower bound is inclusive, and the upper bound is exclusive. For example, a range of 1.1.3 to 3.0.0 matches version 1.1.3, but not 3.0.0.
   Click + to add a row for each additional version or range you want to exclude for that package.
6. Click Save.
7. Optionally, click Add more to add exceptions for other packages.

To update an exception:

1. Click the vertical three dots and select Edit. You can update the package manager, package name, and versions.
2. Click Save.

To delete an exception, click the vertical three dots and select Delete.

​

Set up notifications

Configure Package Firewall notifications to send a Slack message when the firewall blocks or warns on a package installation. Each notification covers the conditions you choose, such as malware, minimum package age, restricted licenses, or vulnerabilities, which are supported for the ecosystem. You can configure multiple notifications for different conditions. A notification is sent only when an event matches both a selected reason and a selected action. The reason must already be configured to block or warn in your policy for it to generate a notification. Each policy shows whether notifications are set up for its selected action, with a link to view or create them. Notifications are not available for the Allow safe versions only (curate) and Do nothing actions. For the Package not evaluated reason, Package Firewall sends a Block notification if the action fails closed and a Warn notification if the action fails open. Package Firewall groups these notifications into one message for each 5-minute window in the root namespace, with a count and a link to the records. If a notification fails to send, the event still appears in the logs. Ensure that you have at least one Slack notification target before you create a notification. Only Slack targets are supported. See Slack integration to set one up.

1. Select Notifications.
2. Click Add notification.
3. Enter a Name for the notification.
4. Select one or more reasons: Malware, Minimum Package Age, Restricted License, Vulnerability, or Package not evaluated.
5. Select one or more actions: Block or Warn.
6. Search for and select the Slack targets that receive the notifications.
7. Click Save.

To edit a notification:

1. Click the vertical three dots and select Edit. You can update the notification name, reasons, actions, and Slack targets.
2. Click Save.

To delete a notification, click the vertical three dots and select Delete.

​

Policy support by ecosystem

Policy support varies by ecosystem because each public registry exposes different metadata. The following table lists the conditions and actions Package Firewall supports for npm, PyPI, Go, Maven, NuGet, RubyGems, and VS Code. The following table explains the conditions that are partially supported or that follow ecosystem-specific rules. Package Firewall skips any condition that an ecosystem does not support. For Go, Maven, and NuGet, the Allow safe versions only (curate) action defaults to Block.

​

How minimum package age is determined per ecosystem

Package Firewall determines a version’s age from the publish time its registry reports. Publish times are exact for every ecosystem except Maven. If the registry returns a version without a publish time, Package Firewall skips the minimum package age check and allows the installation without recording an event. If Package Firewall cannot retrieve the version’s metadata from the registry, it records the event with the reason Package not evaluated.