Install Cert-X-Gen

Install the cxg binary, confirm it runs, and see where it keeps the detection templates it fetches for itself.

Cert-X-Gen is Apache-2.0 licensed and runs on macOS and Linux, on both x86-64 and ARM64. Every release also publishes a Windows binary, which works the same way but is not covered here.

Install

Install script

The shortest path. It detects your platform, downloads the latest release, checks it against the release’s SHA256SUMS, and installs it.

curl -fsSL https://raw.githubusercontent.com/Bugb-Technologies/cert-x-gen/main/install.sh | bash

  ╔═══════════════════════════════════════╗
  ║        CERT-X-GEN Installer           ║
  ╚═══════════════════════════════════════╝

[INFO] Detected platform: darwin-arm64
[INFO] Installing version: v1.6.1
[INFO] Downloading cxg v1.6.1 for darwin-arm64...
[INFO] Verifying checksum...
cxg-darwin-arm64: OK
[INFO] Installing to /usr/local/bin/cxg...

[INFO] Installation complete!

  Run 'cxg --version' to verify installation
  Run 'cxg template update' to download templates

  Documentation: https://github.com/Bugb-Technologies/cert-x-gen

It writes to /usr/local/bin, which usually needs sudo. Set INSTALL_DIR to put it somewhere you own instead:

curl -fsSL https://raw.githubusercontent.com/Bugb-Technologies/cert-x-gen/main/install.sh \
  | INSTALL_DIR="$HOME/.local/bin" bash

This is the one method that follows the latest release rather than a fixed version. Today that is 1.6.1, which is what this site documents. Piping a script into a shell runs whatever that URL serves, so read install.sh first if that matters to you, or use the release-binary tab, which pins a version.

Release binary

Downloads the published build and checks it against the release’s SHA256SUMS. Replace cxg-darwin-arm64 with the asset for your platform: cxg-darwin-amd64, cxg-linux-arm64, cxg-linux-amd64, or cxg-windows-amd64.exe.

1. Download the binary and the checksum file.

   curl -fsSLO https://github.com/Bugb-Technologies/cert-x-gen/releases/download/v1.6.1/cxg-darwin-arm64
   curl -fsSLO https://github.com/Bugb-Technologies/cert-x-gen/releases/download/v1.6.1/SHA256SUMS

2. Verify the download before you make it executable.

   shasum -a 256 -c SHA256SUMS --ignore-missing

   cxg-darwin-arm64: OK

   On Linux, use sha256sum -c SHA256SUMS --ignore-missing.

   If this prints FAILED, stop. Delete the file and download it again.

3. Put it on your PATH as cxg.

   chmod +x cxg-darwin-arm64
   sudo mv cxg-darwin-arm64 /usr/local/bin/cxg

Homebrew

brew install bugb-technologies/cxg/cxg

The user/repo/formula form taps Bugb-Technologies/homebrew-cxg automatically, so no separate brew tap is needed.

The formula is regenerated by cert-x-gen’s release workflow, and it downloads the same release asset as the release-binary tab: same bytes, same SHA256SUMS entry. Check what you got with cxg version.

cargo

Needs a Rust toolchain. This compiles cxg from source, which takes several minutes.

cargo install cert-x-gen

The binary lands in ~/.cargo/bin/cxg. Make sure that directory is on your PATH.

To upgrade a cargo-installed copy later:

cargo install cert-x-gen --force

Which method gives you what

All four give you 1.6.1, which is what this site’s reference documents. Pick on toolchain and upgrade path instead.

Method	Pins a version	Needs a toolchain	Upgrade path
Install script	No, follows the latest release	No	Re-run it
Release binary	Yes, the URL names the tag	No	Download the next tag
Homebrew tap	Yes, the formula’s version	No	brew upgrade
cargo install cert-x-gen	Yes, the crates.io version	Rust	cargo install cert-x-gen --force
Docker image	Yes, the image tag	No, Docker only	Pull the next tag

Verified on 2026-10-19 against the v1.6.1 release: the install script resolved v1.6.1 and its download passed the release’s SHA256SUMS, the release asset passed the same check on its own, the crates.io API reports 1.6.1 as the newest cert-x-gen, the tap’s formula pins 1.6.1, and the container image tagged 1.6.1 reports it. The installer transcript above was captured with INSTALL_DIR pointed at a scratch directory; its Installing to line is shown with the default path, which is the only line that differs.

Upgrade cxg

Upgrade through the method you installed with. cxg update knows the difference: it replaces only a binary that no package manager owns. A cxg in a Homebrew Cellar, in cargo’s bin directory, or inside a container is left alone, and cxg update prints the command that upgrades it and exits 3:

$ cxg update
cxg at /opt/homebrew/Cellar/cxg/1.6.1/bin/cxg is managed by Homebrew, so `cxg update` leaves it alone.
Upgrade it with: brew upgrade cxg
(Pass --force to replace the file anyway.)

Replacing the file behind the manager’s back would leave the manager believing the old version is installed, which is why --force is the only way past it. For a binary from the install script or the release-binary tab, cxg update does the upgrade itself, and checks the download against the release’s SHA256SUMS before it replaces anything:

$ cxg update
cxg is already up to date (v1.6.1)

--check only reports whether a newer release exists. cxg update no longer fetches detection templates on the way; cxg template update does that.

On 1.5.0 or 1.6.0, upgrade once by hand

1.5.0 and 1.6.0 run their own updater, which fails on a Homebrew install with Update failed: IoError: No such file or directory (os error 2). Upgrading with cxg update cannot pick up the fix, so upgrade once through your package manager: brew upgrade cxg, cargo install cert-x-gen --force, docker pull of the new image tag, or a fresh download from the releases page. From 1.6.1 on, cxg update behaves as above.

If you use cxg pentest, its pipeline follows the binary on its own. See after an upgrade.

Run cxg in a container

Every release publishes a multi-architecture image to the GitHub Container Registry. Nothing is installed on your machine, and the image already carries its templates, so the first run scans rather than downloading a catalogue.

docker run --rm ghcr.io/bugb-technologies/cert-x-gen:1.6.1 version

CERT-X-GEN v1.6.1
Advanced Multi-Language Security Scanning Engine

Build Information:
  Version: 1.6.1
  Target:  aarch64-linux

Links:
  Repository:    https://github.com/Bugb-Technologies/cert-x-gen
  Documentation: https://docs.bugb.io/cxg/
  Issues:        https://github.com/Bugb-Technologies/cert-x-gen/issues

:latest also exists. Name the version if you want the run to stay reproducible.

This is also the answer to the warning further down this page. A template runs as the user who invoked cxg, with that user’s files and credentials, and a container is the layer that actually bounds what it can reach. It is not a feature of cxg and cxg makes no isolation claim of its own. See the template trust model.

A container cannot reach your loopback interface

A target bound to 127.0.0.1 on your machine is not reachable from inside the container. To scan a local target from a container you have to bind that target to an interface the container can reach, such as --bind 0.0.0.0, which also exposes it to your network. On Docker Desktop and OrbStack the container then reaches it at http://host.docker.internal:<port>.

For the worked example on Read your first scan, an installed binary is the simpler choice.

Verify the install

cxg version

CERT-X-GEN v1.6.1
Advanced Multi-Language Security Scanning Engine

Build Information:
  Version: 1.6.1
  Target:  aarch64-macos

Links:
  Repository:    https://github.com/Bugb-Technologies/cert-x-gen
  Documentation: https://docs.bugb.io/cxg/
  Issues:        https://github.com/Bugb-Technologies/cert-x-gen/issues

Your Version: and Target: lines will differ. What matters is that the command prints this block rather than command not found.

Templates install themselves

Cert-X-Gen ships without detection templates, and fetches them for you. The first time you run any command on a machine with no templates, cxg announces 📦 First run detected! Installing templates from GitHub..., pulls the official repository, and then carries on with whatever you asked it to do. The line that confirms the fetch is:

[INF] Updated repositories: official

A summary follows, counting the templates it installed and breaking them down by language. Those numbers move with every template release, so treat them as a sign it worked rather than as a figure to remember.

You do not have to do anything to trigger this, and it happens once. Later runs go straight to work with no banner. It does need outbound HTTPS to github.com, so on a machine without it, fetch templates separately and copy them in. The container image is the exception: its templates are baked in at build time, so it works with no outbound access at all.

To pull the latest templates yourself, at any time:

cxg template update

Cert-X-Gen also checks hourly whether newer templates exist. When they do, it prints a line telling you so and leaves the decision to you, rather than updating underneath a scan you are in the middle of.

Where templates live

cxg template pwd

📂 Template Directories (priority order):

  [✗] Local (project)    /Users/you/work/templates
  [✓] User               /Users/you/.cert-x-gen/templates
  [✗] System             /usr/local/share/cert-x-gen/templates

Your paths will differ. A [✓] on User means the auto-install worked, and that is where cxg template update writes.

Local (project) is a templates/ directory in whatever directory you are standing in, and it wins over the other two. That is useful when you are developing templates and surprising when you are not, so it is worth checking this output if a scan runs templates you did not expect.

A template runs as you

cxg starts a template as an ordinary child process with your files, your credentials, and your network access. The templates fetched above are the official set, but the same is true of any template you add. Read the template trust model before running templates you did not write.

Next

• Read your first scan reads a real finding on a target you control, and explains the summary and the results file.
• Scan a target covers scope, template selection, and output formats in full.
• CLI reference has every command, flag, and default.