How It Works

From Repository to Risk Report in Minutes

Connect Meerkat to your Git hosting platform once. It takes care of the rest — scanning, monitoring, enforcing, and alerting — continuously and automatically.

The Process

Six Steps to Full Dependency Visibility

Meerkat's workflow is designed to be set-and-forget. Once configured, every step below runs automatically.

Setup

Connect Your Git Hosting Platform

Provide your Git hosting platform instance URL and a Personal Access Token with read_api scope. Configure which repository groups you want Meerkat to track. Optionally enable the tenant-wide sweep to also cover every project visible to the service account.

Discovery

Meerkat Scans Every Repository

On first run — and every night thereafter — Meerkat walks every project in your configured groups, reads their dependency manifest files, and extracts the full list of packages, versions, and ecosystems. Eight package ecosystems are supported out of the box: npm/yarn, Python, Go, Ruby, Java, PHP, Rust, and .NET.

Indexing

Dependencies Are Indexed & Normalised

Every package — with its name, version, and ecosystem — is stored in Meerkat's database and linked to the project it came from. This makes it possible to answer questions like "which projects use version 1.2.3 of package X?" in milliseconds, regardless of how many repositories you have.

Threat Intelligence

Threat Feed Monitors for New Threats

Meerkat polls a vulnerability intelligence feed on a configurable schedule (default: hourly). When a package is newly flagged as malicious, Meerkat automatically adds it to the deny list and cross-references your index to find every affected repository.

Alerts

Violations Trigger Instant Notifications

When a deny-list or allow-list violation is detected — whether from a CI scan or a threat feed update — Meerkat notifies the relevant project members via email (via a configurable email API) and/or posts a condensed alert to a team chat channel. When a subsequent CI scan comes back clean, Meerkat posts a resolution reply to the original alert thread.

Enforcement

CI Agent Gates Your Pipelines

Add one stage to your .ci-pipeline.yml. The Meerkat CI agent — a single static binary — fires on every build, triggers a rescan of the project, checks the result against your deny and allow lists, and exits with a pass or fail code. Developers see a human-readable summary of any violations directly in the pipeline output. No unapproved package gets merged undetected.

Architecture

Data Flow Overview

How data moves through the Meerkat platform.

Components

What's Inside Meerkat

Web Interface
A React frontend providing the Projects Dashboard, Hunt search, Allow List management, Policy Reports, and Notifications admin page.
Go Backend
A high-performance Go HTTP server handling scanning orchestration, Git hosting platform API integration, threat feed polling, policy evaluation, and notification dispatch.
PostgreSQL Database
Stores all project metadata, dependency records, allow/deny list entries, enforcement targets, scan history, and notification audit logs.
Threat Feed Poller
A background goroutine that polls the vulnerability intelligence feed on a configurable interval and auto-populates the deny list with newly flagged packages.
CI Agent
A standalone static binary that runs inside your CI platform's jobs. It triggers a webhook-based rescan and gates the pipeline based on the policy evaluation result.
Notification Engine
Dispatches alerts via a configurable email API and team chat integration. Supports template rendering, dev overrides, configurable timeouts, and a full dispatch audit log.

See It in Your Environment. Request a Demo.

Request a Demo Read the Docs