titus: a secrets scanner with 487 rules and live credential validation

One engine, four ways in

Titus is a high-performance secrets scanner that detects credentials, API keys, and tokens in source code, files, and git history, and the thing that makes it interesting is that it ships in four shapes: as a command line tool, as a Go library, as a Burp Suite extension, and as a Chrome browser extension, all sharing the same detection engine and rule set.

That last clause is the design. A scanner that is only a command line tool is a tool for a pipeline, and a scanner that is only a browser extension is a tool for a tester looking at one application. Sharing the engine means the same rules, the same validation, and the same scoring apply whether the thing being scanned is a repository, a container image, a proxied HTTP request, or a web page.

The audience is stated as security engineers, penetration testers, and DevSecOps teams, and the combination of features reflects that mix. The passive scanning through Burp finds secrets in traffic, which is a penetration testing activity. The container image scanning and the git history scanning are DevSecOps activities. The library form is for a team that wants to build the checks into their own tooling.

The project is Apache 2.0 licensed, written in Go with a 1.27 toolchain requirement, and the recent releases are v1.2.11 from 2026-10-08, v1.2.10 from 2026-09-28, and v1.2.9 from 2026-08-31, with the last push on 2026-10-19. The rules themselves are drawn from two other scanners, NoseyParker and Kingfisher, which is a sensible starting point for a rule set that covers hundreds of services and credential types.

Why a scanner needs more than a regex

The Why Titus section lists seven reasons, and three of them are the parts that distinguish it from a pattern matcher.

The first is speed, and the mechanism is named. The matching is regex accelerated by Hyperscan, or by Vectorscan, when either is available, with a pure Go fallback for portability on any platform.

The second is coverage: 487 rules that detect API keys, tokens, and credentials for AWS, GCP, Azure, GitHub, Slack, databases, CI and CD systems, and hundreds more services.

The third is the one that changes the workflow. Live secret validation means that detected secrets are checked against their source APIs to confirm whether they are active, which reduces false positives and prioritises remediation. A scanner that finds a hundred candidates and a scanner that finds twelve working keys are very different artefacts for the person who has to rotate them, and only the second one tells you what to do on Monday morning.

The fourth is risk based severity scoring, and it is more elaborate than a threshold. Every finding gets a numeric score from 0 to 100 and a severity tier running from info to critical. The scores are tuned by three things: static rule metadata, code accessibility context, and live API calls that measure the real blast radius of the credential. The stated consequence is that the most dangerous findings always surface first, and the blast radius point is the interesting one, because it is the difference between a key that exists and a key that can list your buckets.

The fifth is container image scanning, from any registry, tarball, or OCI layout directory, with no Docker daemon and no Docker binary required. The sixth is the four interfaces already described. And the seventh is binary file extraction, covering Office documents, PDFs, archives in zip, tar, and 7z formats, mobile apps in APK and IPA form, and browser extensions.

That last one closes a real gap, because a secret in a spreadsheet template or a compiled browser extension is not something a source scanner will ever see.

Scanning targets, from a file to an organisation

The quick start shows the range of targets, and the syntax is a single scan command with a path or a URL.

# Scan a file for secrets
titus scan path/to/file.txt

# Scan a directory for leaked credentials
titus scan path/to/directory

# Scan a public GitHub repository (no token needed)
titus scan github.com/org/repo

# Scan a public GitLab project (no token needed)
titus scan gitlab.com/namespace/project

# Scan git history for secrets in past commits
titus scan --git path/to/repo

titus scan --docker alpine:latest

# Validate detected secrets against source APIs
titus scan path/to/code --validate

The git history flag is worth emphasising, because a secret that was committed and then removed is still in the history and still valid, and that is the single most common finding in a real repository.

The forge scanning is organisation wide when you want it to be, and the subcommands are separate for that.

# Scan all public repos in a GitHub org
titus github --org kubernetes

# Scan all repos in a GitHub org with a token (private repos + higher rate limits)
titus github --org kubernetes --token $GITHUB_TOKEN

# Scan all repos for a GitHub user
titus github --user octocat

# Scan all projects in a GitLab group
titus gitlab scan --group mygroup --token $GITLAB_TOKEN

# Scan a single repo with git history (finds deleted secrets)
titus github scan owner/repo --git

Tokens are optional for public repositories, and they exist for two reasons, private repository access and higher API rate limits, with the environment variable or the flag as the two ways to pass one.

The container scanning deserves its own note, because the implementation is more thorough than the interface suggests. Titus pulls images straight from any OCI registry over HTTPS, using credentials from your Docker configuration file, or reads them from a local tarball or an OCI layout directory. It then scans the manifest and configuration metadata and every regular file in every layer, including files in lower layers that were deleted by later layers, since secrets can remain recoverable from the image history.

Scanning the layers a running container does not have is the part that finds the secrets people do not know about.

Subcommands, and a generated reference

The command line is organised into eight subcommands, and the list is generated into the README rather than written by hand.

titus enum    # Enumerate remote services for secrets
titus explore # Interactively explore scan results
titus report  # Generate a report from scan results
titus rules   # Manage detection rules
titus scan    # Scan a target for secrets
titus serve   # Run as streaming server for Burp extension integration
titus version # Show version information

The separation is worth reading as a workflow. Scan finds candidates, while analyze takes one credential and does the full treatment on demand, which means detecting the type, validating it, scoring it, and enumerating the resources it can reach. Enum finds remote services that hold secrets, which is a different question from what is in the code. Explore and report are for the human looking at the results afterwards.

The deprecated forms are handled carefully. The top level provider forms that predate the enum subcommand still work, but they are hidden and deprecated rather than aliases, so they are listed in the generated reference instead of in the README. The full reference, with every subcommand, alias, and flag including the hidden ones, is generated into the CLI document in the docs directory.

That is a detail that says something about the project. The command surface is large enough that a hand written list in the README would drift, so it is generated, and the same pattern shows up in the repository, which carries a Makefile target for regenerating the command documentation.

The results themselves are written to a datastore, a file named titus.ds by default, and printed to the console.

Acceleration, and the pure Go fallback

The build system is where the performance claim is either real or aspirational, and the Makefile is explicit about it.

Vectorscan and Hyperscan acceleration is the default, and the override is either CGO_ENABLED=0 or the build-pure target, which produces the pure Go fallback. The build tag is vectorscan, and it is cleared automatically when cgo is disabled, because the acceleration library requires cgo, and because an empty build tag argument breaks the build command.

The Makefile also detects the library rather than assuming it. It asks pkg-config whether the library exists and sets a flag accordingly, and on macOS it asks Homebrew for the vectorscan prefix and prepends that to the pkg-config path, so a Homebrew installation is found without the developer configuring anything.

The build itself turns the workspace off, passes the cgo setting and the tag, and writes the binary to the distribution directory.

build: $(BUILD_DEPS)
	@mkdir -p dist
	GOWORK=off CGO_ENABLED=$(CGO_ENABLED) go build $(TAGS_FLAG) $(LDFLAGS) -o dist/titus ./cmd/titus

And the build is told to check for the library first when it needs it, which is what the check-vectorscan target is for.

For a user, the practical question is which build you want. The accelerated build is for a machine scanning a large estate, and the pure Go build is for a laptop, a container image, or a platform where the acceleration library is awkward to install. The fallback exists so that the tool is never unusable for the sake of a build flag.

The module dependencies tell the same story from a different angle. The matching uses the Cloudflare ahocorasick library and the dlclark regexp2 engine, the interface is built on the charmbracelet set of terminal components, and the forge and cloud clients are the AWS, Azure, Google, GitHub, and GitLab SDKs, with the GitLab client being a separate module rather than a GitHub library with a different base URL.

The library, the extensions, and the parts you cannot see

The Go library form is one of the four interfaces, and the dependency list gives a hint of what a program that embeds it looks like. There is a capability SDK in the dependencies, and the repository topics include capability, which is the vocabulary of measuring what a credential can reach. There is a recording library for HTTP fixtures, a modern pure Go SQLite driver, a MongoDB driver, a MySQL driver, and a Postgres driver, so the datastore that holds results and the state of a scan is not a format you have to learn before you start.

The Burp integration has its own subcommand, serve, described as running as a streaming server for the Burp extension integration. That is the passive scanning path, and it means the scanner sits in the request path of a proxied session rather than being pointed at a directory, which is how a secret in a response body or a header gets found during an application security test.

The Chrome extension is a separate directory in the repository, and the build file for it is a Gradle project rather than a Go one, so the browser extension is a different codebase sharing the compiled engine. There is a WebAssembly build target in the Makefile as well, and a wasm directory, which is the same trick again, the detection engine compiled to run in a browser with no server behind it.

That three-way split, native, browser, and WebAssembly, is the practical answer to the question of how the same rules reach a web page during a test and a repository during a pipeline. The engine is the shared part, and the interfaces are thin.

What to check before you rely on it

A few things decide whether this tool is useful in your environment.

The first is whether you can make validation calls. The live validation step is the feature that separates a useful finding from a regex match, and it means outbound requests to the API that issued the credential. In an environment with an egress policy, that is a real constraint, and the scanner is more useful with validation on for the providers you care about than off for all of them.

The second is acceleration. If you are scanning a large estate of repositories, the difference between the accelerated and pure Go builds is the difference between a scan that finishes and one that does not, and the Makefile gives you both with one variable.

The third is scope. A scan of the working tree is what every other tool does, and the git history flag, the container image flag, and the organisation wide subcommands are where the additional findings are. A deployment that scans only the current tree will keep finding the same secrets it found last quarter.

On the project itself, the licence is Apache 2.0 with a NOTICE file in the repository, there is a code of conduct, a contributing guide, a golangci configuration, and a large test suite with a testdata directory, plus Makefile targets for recording and scanning fixtures, which is what a project with this many detection rules needs in order to test that the rules still fire.

The releases move every few weeks at a patch level, and the last push was on 2026-10-19, so the rule set is being kept current rather than frozen.

Editorial conclusion

titus fits a security team that wants more than a grep for known key prefixes, because the live validation step turns a list of candidates into a list of credentials that are still working, and the container image scanning reaches secrets that are not in the source at all. It does not fit a workflow that cannot make outbound validation calls, since checking a credential means calling its API, and it does not fit a team that only wants a pre-commit hook. Verify first that your build has the acceleration library available or that the pure Go fallback is acceptable for your volume, that the rules you rely on are enabled for your providers, and that the scan targets you pass include the history and the images, since a scan of the working tree alone is what most tools already do.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. praetorian-inc/titus on GitHub
3. Project website
4. README
5. Releases