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

Keep bad packages out

Malware scanning for every cached package and image layer

Every file ForgeRepo™ caches, of every package type, can be run past one or more scanners before your builds get it. A verdict of malicious rejects the file, and suspicious holds it for a person to look at.

Four scanners ship, and they all answer in the same shape (clean, suspicious, malicious, error or not scanned), so the policy never cares which one said it. Results are kept per SHA-256, so identical bytes under two names are scanned once.

  • Known malicious packages (OSV). Asks osv.dev whether the exact name and version is in the OpenSSF malicious packages feed, the advisories named MAL-. A hit is malicious. Only names and versions leave the box, never the file. It covers npm, PyPI and every other type OSV has a feed for, which is all of them except container images and CocoaPods. If osv.dev cannot be reached the answer is an error, never a quiet clean. It only knows what has been reported, so it sits next to a content scanner rather than replacing one.
  • ClamAV. A clamd ships in the compose file. Put COMPOSE_PROFILES=clamav in .env, bring it up, and point ForgeRepo™ at host clamav, port 3310. It publishes no port, since clamd has no authentication, and takes files up to 4000 MB.
  • A hash blocklist. SHA-256 values you already know are bad, one per line.
  • Your own scanner. ForgeRepo™ POSTs the file to a URL with its SHA-256 and name, and takes JSON back. Redirects are refused and the answer is capped at 1 MB. YARA, a sandbox or a commercial engine each fit behind this.

Scanning as a whole is off until you switch it on under Settings, Malware. The scanner list then starts as blocklist, ClamAV and OSV. A box with no way out to the internet should take osv off the list, or every file will come back as an error.

By default new files are scanned in the background as they are cached, so the very first download of a brand new file can go out before its scan is done. Scan before serving closes that gap: a file with no answer yet is scanned on the spot and refused with a 503 if that takes more than a minute. Files whose exact bytes already scanned clean go straight out. If ClamAV goes down, files it already passed keep flowing and new ones wait; they are scanned and served as soon as it is back, and a small watchdog restarts a ClamAV that has stopped answering.

Known malicious after the fact

A MAL- advisory is often published after a version was already cached. The scheduled vulnerability scan catches it, and with Kill known-malicious packages by themselves on, which is the default, the advisory goes on the kill switch as soon as it is recorded and admins get the kill switch mail. It is added once: an admin who lifts it keeps it lifted.

Admins get an email within a minute of a new malicious or suspicious verdict, several close together share one mail, and a daily digest lists whatever is still held.

To be plain about it: ClamAV finds what its signatures know, and the OSV feed knows what somebody has reported. Neither is the same as a commercial feed built by a research team that reads new packages all day. That is why the other layers exist too: cooling off, typosquat checks, the kill switch and advisory feeds.

packages.example.com/_admin/
Settings, Malware. Pick the scanners, what each verdict does, and whether to scan before serving.

In short

  • ClamAV, a SHA-256 blocklist, a generic REST scanner and the OpenSSF known malicious feed, any combination
  • Every cached file of every type, image layers included
  • Malicious rejects through quarantine, suspicious holds, both configurable
  • Scan before serving for new files, with a one minute ceiling
  • A MAL- advisory published later goes on the kill switch by itself
  • Email to admins within a minute, and a daily digest
  • Detections land in the audit trail as malware.detected and as SIEM events

In the documentation

Goes well with

  • Integrity alerts and quarantine A file that changes after it was first seen is held. The original keeps being served.
  • Cooling off new releases Brand new versions wait a few days before your builds see them, which is when hijacks get caught.
  • Kill switch Take a package, a version range, one file hash or a whole advisory away from everyone, at once.

One container, about two minutes

A Linux box with Docker, or one without it, and a reverse proxy for TLS. The installer does the rest and it is safe to run twice. Free, MIT licensed, nothing to sign up for.