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. Scenarios: what happens, and what you do

Incident response

Scenarios: what happens, and what you do

Real incidents walked through step by step.

  • Automatic: in whitelist mode with pinned ranges, the new version is not covered by any rule and never installs. With cooling off on, it is hidden for the waiting period. With malware scanning, a MALICIOUS verdict rejects it and emails admins. If the attacker replaces a version you already hold, an integrity alert holds it and the original bytes keep being served.
  • You: kill the bad versions with a reason that names a safe version. Use who pulled it and Consumers to find affected builds. Raise the registry mode to degraded if the whole ecosystem is under attack.

2. A developer mistypes a package name

  • Automatic: in whitelist mode the unknown name is refused as not on the whitelist and a request opens. In blacklist mode the lookalike check warns or blocks.
  • You: block the request with a reason naming the real package. Consider Typosquat checks: block.

3. Docker Hub is down

  • Automatic: cached layers are served, and tags confirmed in the last 7 days keep working. Uncached layers fail with a 502.
  • You: switch to lockdown, or turn off Upstream registry enabled, to serve kept images at any age until Docker Hub is back.

4. A critical CVE is published for a version you allow

  • Automatic: the next scan records the finding, npm warns during installs, npm audit reports it, and downloads are logged. With safe version resolution on, installs move to the newest safe version in range and exact downloads are refused.
  • You: check Vulnerabilities and Consumers. If teams need time, grant scoped waivers with an end date. For an actively exploited advisory, kill it by advisory id.

5. Someone publishes your internal package name on public npm

  • Automatic: if the name is reserved, the public copy is never fetched. Otherwise the public package could be installed.
  • You: reserve the scope or prefix now, keep fall back off on internal registries, and search Consumers for the public name.

6. A token leaks in a public repository

  • You: revoke it on Tokens, then filter Traffic by its application and look for unfamiliar addresses. Consider the client allow list with Let a valid token through from any network off.