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. How ForgeRepo™ works

How it works

How ForgeRepo™ works

One registry for npm, PyPI and container images that checks every download against your rules and your security settings.

ForgeRepo™ answers npm, pip and docker at packages.example.com. It fetches packages and images from the public registries, keeps a copy, and serves them only when every check agrees. Nothing is installed straight from the internet.

npm, pip ordocker asks1. Kill switch2. Rules forthis token3. Lookalike name check4. Fetch or use the cache(reserved names, registrymode)5. Quarantine, vulnerabilities,cooling off, licenses6. File hash kill and scanbefore serve403 with the reason, maybea requestServedany check says no
The order of checks for a download. Metadata requests go through the same checks and simply leave out versions that would fail.
  1. Kill switch. Beats everything, including allow rules and audit mode.
  2. Rules. Whitelist or blacklist, scoped by the token's application and environment.
  3. Lookalike names. Warns or blocks names that imitate popular packages.
  4. Fetch. Reserved names are never fetched from outside. Degraded and lockdown modes limit what is fetched.
  5. Holds and policies. Quarantine holds, safe version resolution for known vulnerabilities, cooling off for brand new releases, and license rules.
  6. Last checks on the file. A kill by file hash, and an optional malware or image scan before the file is served.

Two ways a version is left out

  • In metadata. When npm or pip asks which versions exist, blocked versions are removed and latest moves to the newest allowed version. The client picks an allowed version on its own.
  • On download. A lock file asks for an exact file. That request runs every check again and gets a 403 with the reason.

Note

Checks run on the server for every request. Hiding a button in the portal is only tidiness. Roles are enforced by the API.

See also: Writing rules, Applications, environments and token scope, Registry modes: degraded and lockdown