Rusty Hog: regex secret scanners for S3, Git, Google Docs, JIRA, Slack and Confluence

Seven binaries, one per source, built around regular expressions

Rusty Hog is a secret scanner built in Rust for performance, and based on TruffleHog which is written in Python. Rusty Hog provides the following binaries.

Ankamali Hog scans for secrets in a Google doc. Berkshire Hog scans for secrets in an S3 bucket. Choctaw Hog scans for secrets in a Git repository. Duroc Hog scans for secrets in a directory, file, and archive. Essex Hog scans for secrets in a Confluence wiki page. Gottingen Hog scans for secrets in a JIRA issue. Slack Hog scans for secrets in a Slack Channel.

The naming is decorative. What matters operationally is that the scanners are separate binaries rather than one tool with subcommands, so each source has its own credential requirements, its own authentication flow and its own flags, and you can run exactly the scanner you need without carrying the dependencies of the others.

The detection mechanism is the same across all of them. This project provides a set of scanners that use regular expressions to try and detect the presence of sensitive information, such as API keys, passwords, and personal information. It includes a set of regular expressions by default, but also accepts a JSON object containing your custom regular expressions.

So the scanning model is pattern matching over content, with two escape hatches. There is entropy scanning, exposed as a flag on the GDoc scanner, and there is a custom regex JSON file and a custom allowlist JSON file.

The scanner crate is separate from the binaries. The Cargo manifest declares a workspace with one member, crates/rusty-hog-scanner, and the root package depends on it by path. That means the scanning logic, including the regex engine and the entropy threshold, is one library that all seven binaries share, and the per-source work is only about authentication and content retrieval.

The dependency list in the manifest shows the shape of that: git2 for Git, rust-s3 with the blocking feature for S3, google-drive3 and yup-oauth2 for Google, hyper with the client feature and hyper-rustls for the HTTP sources, walkdir for directories, and zip, tar and flate2 for archives.

Running a scanner means supplying credentials and reading a JSON report

The GDoc scanner's help output is the clearest illustration of the common interface, and the flags are worth reading because they are the vocabulary for every scanner.

USAGE:
    ankamali_hog [FLAGS] [OPTIONS] <GDRIVEID>

FLAGS:
        --caseinsensitive    Sets the case insensitive flag for all regexes
        --entropy            Enables entropy scanning
        --oauthsecret        Path to an OAuth secret file (JSON) ./clientsecret.json by default
        --oauthtoken         Path to an OAuth token storage file ./temp_token by default
        --prettyprint        Outputs the JSON in human readable format
    -v, --verbose            Sets the level of debugging information
    -h, --help               Prints help information
    -V, --version            Prints version information

OPTIONS:
    -a, --allowlist <ALLOWLIST>                                    Sets a custom allowlist JSON file
        --default_entropy_threshold <DEFAULT_ENTROPY_THRESHOLD>    Default entropy threshold (0.6 by default)
    -o, --outputfile <OUTPUT>                                      Sets the path to write the scanner results to (stdout by default)

        --regex <REGEX>                                            Sets a custom regex JSON file

The structure is consistent across the tools. A positional argument identifies the target, in this case the ID of the Google drive file you want to scan. Credentials for the Google path come as a path to an OAuth secret file and a path to an OAuth token storage file, with defaults of ./clientsecret.json and ./temp_token.

The output goes to stdout by default, and --outputfile writes the results to a file instead. --prettyprint makes the JSON human readable, which is the flag to reach for when you want to read a finding rather than pipe it somewhere.

Two flags carry real scanning semantics. --entropy enables entropy scanning, and --default_entropy_threshold sets the bar, at 0.6 by default, so a string that looks random enough to be a key can be flagged even when no regex matches it. And --caseinsensitive applies to all regexes, which matters because provider keys are not uniformly cased.

The allowlist and the regex file are the two customisation points, and both are JSON, which means they can be generated by another tool or shared across a team. The allowlist is the one that matters operationally, because a scanner that flags every known test key produces noise nobody reads.

Three ways to run it: downloaded binaries, Docker Hub, or a local build

The Usage section offers three routes, and the README is clear that each one has a cost.

The first is downloading the binaries. Download and unzip the latest ZIP on the releases tab, then run each binary with -h to see the usage. The example uses wget with a versioned release URL, unzips it and runs the macOS binary.

```shell script wget https://github.com/newrelic/rusty-hog/releases/download/v1.0.11/rustyhogs-darwin-choctaw_hog-1.0.11.zip unzip rustyhogs-darwin-choctaw_hog-1.0.11.zip darwin_releases/choctaw_hog -h

The second is DockerHub. Rusty Hog Docker images can be found at the authors personal DockerHub page, and a Docker Image is built for each Hog and for each release. The example pulls and runs the choctaw_hog image with --help.

shell script docker pull wetfeet2000/choctaw_hog:1.0.10 docker run -it --rm wetfeet2000/choctaw_hog:1.0.10 --help ```

That image naming is worth noting. The images live under a personal Docker Hub account rather than an organisation namespace, so the images are not managed by New Relic as a project asset, and a pull of wetfeet2000/choctaw_hog is a pull from one person's account.

The third is building it yourself. Ensure you have Rust installed and on your path, clone this repo, and then run cargo build --release, with the binaries located in target/release. Documentation is built with cargo doc --no-deps --open, and unit tests run with cargo test.

The build system itself is a Makefile with a check-version guard that fails when VERSION is undefined, and a docker-build target that builds a shared rust-builder image and then one tagged image per scanner, ankamali, berkshire, choctaw, duroc, essex, gottingen and hante. The docker-save and docker-load targets produce and consume a single images.tar with all seven images, and docker-publish pushes them all.

So the Makefile is built around shipping all seven images as a set, which is the right shape for an organisation that wants to standardise a scanner across its tooling.

Building for AWS Lambda means cross compiling with musl and static OpenSSL

Berkshire Hog is the one scanner with a second deployment story, because scanning an S3 bucket at scale is a job for a Lambda function rather than for a laptop.

The general cross-compilation recipe uses a musl builder container and then packages the binary.

```shell script docker run --rm -it -v "$(pwd)":/home/rust/src ekidd/rust-musl-builder cargo build --release cp target/x86_64-unknown-linux-musl/release/berkshire_hog bootstrap zip -j berkshire_lambda.zip bootstrap ```

The Cargo manifest declares this as a cross configuration, with a package.metadata.cross entry for the x86_64-unknown-linux-musl target pointing at Dockerfile.lambda. So the musl target and the Lambda Dockerfile are wired into the build system rather than being separate scripts.

The platform-specific build scripts are build_lambda.sh for Linux and build_lambda_macos.sh for macOS. On macOS you use Homebrew to get the dependencies, brew install rpm2cpio FiloSottile/musl-cross/musl-cross, then run ./build_lambda_macos.sh. On Linux, make sure cross is installed with cargo install cross, then just ./build_lambda.sh.

Both scripts take overrides. The macOS script will build against OpenSSL 3.0.12, with export OPENSSL_BUILD_VER=3.0.12 to override, and will build against Amazon Linux kernel headers provided by their RPM, with export AMAZON_KERNEL_HEADERS_RPM_URL=... to override where the RPM is downloaded from. The README is explicit that nothing prevents a different distribution's linux-headers RPM from being used, since the requirement is only that the headers build OpenSSL for Linux.

The macOS script also manages a build-deps directory in the source root, which you can remove safely because it is recreated on the next run, and it performs consistency checks that may ask you to remove the directory and try again.

Building on Windows is a different problem again, because OpenSSL has to be built statically first. The instructions compile static OpenSSL binaries with vcpkg, and point Cargo at them with two environment variables, OPENSSL_DIR and OPENSSL_STATIC, the latter set to Yes, and set both at the user level so they persist.

Where Rusty Hog is the wrong tool

The first wrong-tool case is a team that needs verified credentials rather than detected strings. The detection here is regular expressions plus an entropy threshold, which finds things that look like secrets. It does not call a provider to check whether a key still works, so it cannot tell you whether a match is a live credential or an example key from a public README. TruffleHog, which this is based on, has verification behaviour in some of its detectors, and if you need that, the upstream Python project is the place to look rather than this port.

The second case is a whole-organisation secrets posture. These are seven source-specific scanners, each with its own authentication model: a Google OAuth secret file, AWS credentials for the bucket scanner, a Git repository URL, a Confluence wiki page, a JIRA issue, a Slack channel. That is a good fit for a targeted sweep of one system, and a poor fit for running continuously across everything, because there is no central configuration, no scheduled scanning, no baseline and no alert pipeline.

The third case is a team that needs the Docker images to be a trusted supply chain artefact. The images are published under a personal Docker Hub account rather than an organisation namespace, so they are not covered by an organisation's image scanning, signing or pull-through cache. A team with an image allowlist will need to build its own images from source, which the Makefile supports.

The maintenance picture is the one to weigh carefully before adopting. The recent releases are v1.0.11 from 2021-09-20, v1.0.9 from 2021-04-16 and v1.0.8 from 2020-08-11, and the last push to the repository was on 2026-08-03. So the packaged versions are about five years old while the repository is being worked on. That gap usually means the recent work is on the branch rather than in a tagged release, and the version in the Cargo manifest is still 1.0.11. Anyone building from source is running untagged code, and anyone downloading a release is running five year old code.

The dependency versions tell a similar story. git2 is pinned at 0.18, rust-s3 at 0.33, hyper at 0.14 with hyper-rustls at 0.24, and zip at 0.6, with rust-s3 using the blocking feature. Those are not current versions, and a scanner that reaches out to Google, AWS, Slack, JIRA and Confluence over the network is exactly the kind of program where an old HTTP or TLS stack is worth checking against your own vulnerability scanning.

On licence, Apache-2.0 with a LICENSE file at the root and a THIRD_PARTY_NOTICES.md for the vendored dependencies, which is the permissive grant with no copyleft obligation and no restriction on commercial use. The dependency list in the manifest is broad, spanning AWS, Google, Atlassian and Slack clients plus TLS, so a compliance review has more than the crate itself to look at.

Editorial conclusion

Rusty Hog suits a team that wants to sweep a specific source such as one S3 bucket or one Git repository for leaked credentials with a tool that runs fast and produces a plain JSON report, since each source has its own binary with a documented flag set and a custom regex file. It does not suit a team that needs to verify live credentials, since the detection is pattern and entropy based rather than validation based. Before adopting, check the release dates first, because the newest tag is v1.0.11 from 2021-09-20 while the last push was on 2026-08-03, and read the allowlist JSON format so known false positives can be filtered.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. newrelic/rusty-hog on GitHub
4. README
5. Releases