Product

Overview

How it works Watch it work All 35 features Screenshots How ForgeRepo™ is secured

Keep bad packages out

Malware scanning Typosquat detection Dependency confusion protection Cooling off new releases Allow lists and block lists

When something goes wrong

Kill switch Who has it Lockdown and degraded modes Vulnerability monitoring

Developers and approvals

Requests and auto approve Check, walk and review Waivers Dry run
Formats

Languages

Private npm registry PyPI proxy and private index Private NuGet feed and proxy Maven repository proxy RubyGems mirror Composer and Packagist proxy

Apple, containers and Linux

CocoaPods CDN mirror Swift package registry Docker registry mirror RPM mirror for dnf and yum APT mirror for Debian and Ubuntu

Use it as

An npm firewall Artifacts, SBOMs and lifecycle More than one node SSO, roles and allow lists
Learn

Guides

Learn secure development Secure coding Secure pipelines Unsafe vs safe Security and development

Supply chain

Supply chain attacks, 2016 to 2026 Software supply chain security
Compare Side by side, all four ForgeRepo™ vs JFrog ForgeRepo™ vs Sonatype ForgeRepo™ vs Cloudsmith
Docs

Start

Getting started Download All documentation Questions

For developers

npm setup pip setup docker login Push a Docker image CI basics

For administrators

First setup Rules and their order Six incidents, walked through Backup and upgrade
Pricing Install it
  1. Home
  2. Documentation
  3. Administrator Guide
  4. The kill switch

Incident response

The kill switch

Stop a malicious package everywhere at once and find everyone who has it.

1. Kill it, with areason2. Who pulled it(last 30 days)3. Consumers: appsand pipelines4. Fix, then liftthe kill
12
  1. What to kill: a package, one file by sha256, or an advisory
  2. Everyone who downloaded it in the last 30 days
KillStops
A packageEvery version, or a range, tag or digest you name. Exact names only.
One file, by its sha256That exact file under any name, including copies that turn up later.
An advisoryEvery version the vulnerability scan has recorded against a CVE, GHSA or PYSEC id.

Hundreds at once, from a CSV

When an advisory lists a whole campaign, admins can use Kill from a CSV. One row per package: package, version, type. Type is npm, pypi (or python) or oci (or docker). An empty version kills every version.

campaign.csv

package,version,type
event-stream,3.3.6,npm
ua-parser-js,0.7.29 || 0.8.0 || 1.0.0,npm
requests,==2.31.0,pypi
library/nginx,1.25.3,docker
flatmap-stream,,npm
  1. Pick the file or paste the rows, and write the reason.
  2. Click Check the file. The list shows every package, which are already killed, and each row that cannot be read with its line number. Nothing is killed yet.
  3. Click Kill N package(s) and confirm. Rows for the same package become one kill. Admins get one email with the list, and each kill is in the audit trail.
  1. Open Kill switch and fill in Kill something. The reason is shown to every developer who is refused, so say what to use instead.
  2. Tick Also delete the cached copies now if the files must not stay on disk.
  3. Click Kill it. It takes effect within seconds, beats every allow rule, scope and waiver, and works in audit mode.
  4. Use who pulled it for the last 30 days of downloads by token, application, environment and address. Admins and approvers also get this by email.
  5. Use Consumers for the longer history and a per application SBOM.
  6. When it is safe, lift the kill with a note.