Secret Multiscanner

The Secret Multiscanner is RedAmon's deep secret-scanning engine. It searches 14 different kinds of target for exposed credentials using 1060 detectors, and it can go one step further than any regex scanner: it calls the owning service's API with the credential it found and tells you whether it is actually live.

It runs outside the recon pipeline. You configure it once per project, in project settings > Other Scans > Secret Multiscanner, and you start it per source from the Other Scans modal in the Red Zone.

Table of contents

• How it works
• Verification: the switch that matters
• Step 1: set the keys
• Step 2: the settings page, control by control
  • Section header
  • Sources block
  • Shared options block
  • The detector picker
  • Field types used by the source cards
• The 14 sources, field by field
  • 1. Git repository
  • 2. GitHub
  • 3. GitHub deleted commits
  • 4. GitLab
  • 5. Docker registry
  • 6. Hugging Face
  • 7. AWS S3
  • 8. Google Cloud Storage
  • 9. Filesystem
  • 10. Jenkins
  • 11. Elasticsearch
  • 12. Postman
  • 13. CircleCI
  • 14. Travis CI
• Advanced shared options
• Step 3: run the scans
• Understanding results
  • Graph model
  • How a finding is labelled per source
  • Where to see these nodes
  • Deduplication and re-runs
• Security model
• Troubleshooting
• Next steps

How it works

Three ideas explain the whole feature.

One source, one scan. A source is a place secrets can hide: a Git repository, a GitHub org, a Docker registry namespace, an S3 bucket, a Jenkins instance. You add each source you care about as its own card in project settings, and each card becomes its own startable scan in the Other Scans modal. Adding "GitHub" and "Docker registry" gives you two independent scans with their own Start, Stop, Logs and status.

Sources run in parallel. A Docker Hub scan and a Hugging Face scan can be in flight at the same time. The only thing refused is a second run of the same source while the first is still running. There is no scanner-specific parallelism cap: admission goes through the same memory governor as every other scan, with a per-source memory envelope (768 MB by default, 1.5 GB for Docker and Hugging Face, 1.125 GB for S3 and GCS).

Shared options apply to all sources. Verification, result types, concurrency and the detector lists live on the project, not on the card. Change them once and every source uses the new value, including sources that are already queued.

Each source has:

An exposed, unauthenticated Jenkins or Elasticsearch scans without any credential, and is itself a finding worth reporting.

Verification: the switch that matters

Unlike a regex-only scanner, the Secret Multiscanner can verify a finding by calling the owning service's API with the credential it just found: AWS keys go to STS GetCallerIdentity, GitHub tokens to GET /user, Slack tokens to auth.test. A verified finding is a confirmed live credential, which is the highest-value result in an authorised engagement.

This is an ACTIVE behaviour. RedAmon transmits found credentials to third-party services to test them. The scanner's badge reflects that in real time: it reads ACTIVE when verification is on and PASSIVE when it is off. The blast-radius control is the Exclude detectors list: an excluded detector is never contacted at all.

Every finding carries a validation_status, and the four values mean genuinely different things:

A footgun that no longer exists. The old UI had two independent toggles, "Only Verified" and "Skip Verification". Enabling both asked the engine to report only verified results while forbidding it to verify anything: zero findings, no error. There is now one always-visible switch plus a separate result-type filter that greys out when verification is off.

Step 1: set the keys

The Secret Multiscanner has its own keys, grouped under Global Settings > API Keys > Secret Multiscanner. They are deliberately separate from the GitHub Secret Hunt Token and the Supply Chain GitHub Token, which belong to GitHub Secret Hunting and Supply Chain Scanning and are themselves two different keys. Keys are stored per user, shared across all of that user's projects, and are never included in a project export.

There is one key per source, or several where the service allows several auth styles.

If a source's key is mandatory and empty, its card shows missing <key name> in red, its Start button is disabled, and the card links straight to the field. The server re-checks at start time, so a queued scan whose key was cleared in the meantime also fails closed.

Setting a key without leaving the form. Every source card, and every blocked row in the Other Scans modal, carries an inline editor for the keys that source declares:

Bulk entry. Global Settings > API Keys has a downloadable JSON template and an import button, and all 19 of these keys are in it, so an air-gapped operator can fill them in offline and import them in one go.

Step 2: the settings page, control by control

Open project settings, go to the Other Scans tab, and find the Secret Multiscanner section.

Sources can only be managed on a saved project. In create mode the section shows the shared options only and says "Save the project first, then add the sources to scan here."

Section header

Sources block

This is the top block, because the sources are the scan. Everything below only modulates them.

Inside an expanded source card:

Source cards save immediately. Every change inside a source card is written to the server as you make it. The shared options below are part of the project form and are saved with the form's Save button.

Rules the sources block enforces:

• One profile per source per project. This is a database constraint, not a convention, and it is the same rule that makes "one run per source" true at scan time. A double-submitted add is answered with "A <source> profile already exists for this project" rather than a second card.
• Cards are listed in the order they were added, and that is the order the Other Scans rows appear in.
• No credential may live in a source config. A write containing a field named like a token, password, secret or API key is refused, with a message pointing at the key group instead. So is a field the source does not declare. The refusal is deliberate rather than a silent strip, because a project export copies a profile's config verbatim.
• Deleting a source removes the card and its scan row. Findings already written to the graph stay until that source is re-run or the graph data is cleared.
• With no sources yet, the block reads "No sources configured yet. Add one below to make it startable from Other Scans."
• A failed add or save shows a red banner above the cards with the server's reason.

Shared options block

Header: SHARED OPTIONS, with the hint "Applied to every source above."

Verify secrets against live APIs

Result types

Concurrency

Include detectors

Exclude detectors

The detector picker

Both detector fields have a Browse all 1060 button that opens the full catalogue inline. It exists because the fields are free text whose only valid values are 1060 exact, case-sensitive names that appear nowhere else in the UI.

The detector list is regenerated whenever the pinned scan engine is upgraded, because a new version adds detectors and a name copied from a stale list produces a scan that refuses to start.

Field types used by the source cards

Every source field below is rendered from its declared type. The same type also decides how the value is turned into a command line, so what you type and what the engine receives cannot drift apart.

Two more rules apply everywhere:

• A field marked with * is required. Cross-field rules ("one of A or B") appear as validation errors instead.
• A field with a dependency renders at 50% opacity and is disabled until the field it depends on has a value. GitHub's org-only options depend on Organizations; Hugging Face's sweep options depend on Mode being "Organization / user sweep".

The 14 sources, field by field

The last column is the scan-engine flag the field becomes, included so a run can be traced back to exactly what was executed. positional means the value is passed as the scan target itself rather than behind a flag.

1. Git repository

Any Git host over https://, ssh://, git:// or file://. Also scans a local mirror clone with no network at all.

Asset produced: MultiscannerRepository. Credentials: Git Username (optional), Git Token (optional). A credential is only required when the URI starts with ssh://.

Validation rules

• Set a Repository URI or a Local repository. Neither is an error.
• The two are mutually exclusive: one run scans one repository.
• A local repository name must be a single path segment matching [A-Za-z0-9][A-Za-z0-9._-]*. No slashes, no ...

Scan descriptor: local:<name>, or the URI with any embedded credentials stripped.

2. GitHub

Repositories, organizations, wikis, gists and issue / PR / gist comments.

Asset produced: MultiscannerRepository. Credential: Secret Multiscanner GitHub Token, always mandatory.

Validation rules

• Set at least one repository or organization.
• Include repos, Exclude repos and Include member repos apply only to organization scans. Setting one without an org is refused.

Scan descriptor: the orgs followed by the repos.

Why GitHub findings do not split into duplicate nodes. GitHub reports a repository in two shapes: a clone URL for a finding in a file, and a bare owner/repo for one in an issue or PR comment. RedAmon canonicalises both to the clone-URL form, using the host from the finding's own link so a GitHub Enterprise repository is never renamed to a github.com one.

3. GitHub deleted commits

Finds secrets in force-pushed and deleted commits, which are the canonical leak pattern: commit a key, notice, revert, force-push. The tip looks clean but the original blob is still in the object database.

Asset produced: MultiscannerRepository. Credential: Secret Multiscanner GitHub Token, always mandatory. The engine's object-discovery submodule is always enabled, because the command errors out without it.

This source is far slower than a normal GitHub scan, and its findings have no live file path: the blob no longer exists on any branch.

4. GitLab

GitLab.com or a self-hosted instance.

Asset produced: MultiscannerRepository. Credential: Secret Multiscanner GitLab Token, always mandatory.

Validation rules

• A repository, if given, must be a full http(s) URL. org/repo is refused with a suggested rewrite, because the engine answers the shorthand with an INFO-level notice and then scans nothing for it: a silent miss rather than a failure. GitHub accepts the shorthand, which is exactly why this trap is worth guarding.
• Empty repos plus empty groups is legal and means "everything the token can see".

Scan descriptor: the repos and group:<id> entries, or the endpoint, or gitlab.com (all visible).

5. Docker registry

Docker Hub or any OCI registry. Scans image layers and the build history baked into RUN / ENV directives.

Asset produced: MultiscannerImage. Credential: Secret Multiscanner Docker Token, mandatory when a namespace is set or "Include private images" is on.

Validation rules

• Set at least one image or a namespace.
• An image containing :// is refused: docker:// needs the Docker socket, which a scan container never gets, and file:// would read the container's own filesystem.
• An image must match a bare-reference shape: name, optional :tag, optional @sha256:<64 hex>.
• A namespace containing shell metacharacters or a leading dash is refused.
• A local image tarball name must be a single path segment with no slashes.

Expansion behaviour: with "Scan all tags" or "Scan all architectures" on, RedAmon lists the tags from Docker Hub and expands each reference into per-tag or per-architecture digests, stopping at Max images. A listing error is fail-soft: the original reference is scanned as-is rather than aborting the run.

Scan descriptor: the image list plus local:<name> entries, or the namespace.

A secret found in an image's build history has a synthetic path that exists in no filesystem. RedAmon marks these finding_kind: image_history and renders the location as "Dockerfile (build history)" so nobody goes looking for a file that is not there.

6. Hugging Face

Models, spaces and datasets, either as named assets or as a whole organization / user sweep.

Asset produced: MultiscannerModel. Credential: Secret Multiscanner Hugging Face Token, optional.

Every field marked Sweep only is greyed out and disabled while Mode is "Specific assets".

Validation rules

• Specific assets mode: set at least one model, space, dataset or bucket.
• Sweep mode: set at least one organization or user.

Scan descriptor: orgs, users, models, spaces, datasets and buckets, joined.

7. AWS S3

S3 buckets, optionally across assumed roles.

Asset produced: MultiscannerBucket. Credentials: AWS Access Key ID and AWS Secret Key (mandatory unless cloud environment IAM is on), AWS Session Token (optional, STS only).

Validation rules

• Buckets and Ignore buckets are mutually exclusive.

Scan descriptor: the bucket list, or all reachable buckets.

8. Google Cloud Storage

GCS buckets, authenticated or public-only.

Asset produced: MultiscannerBucket. Credential: GCP Service Account JSON, mandatory unless "Without auth" or "Use cloud environment ADC" is on. The JSON blob is written to the run directory and passed as a file path, because the flag takes a path and not the key itself.

Validation rules

• Project ID cannot be combined with Without auth.
• Set a Project ID or enable Without auth. Neither is an error.

Scan descriptor: the project ID, or public buckets.

9. Filesystem

Scans a RedAmon-owned folder on the host: scanners/scan_targets/filesystem/. Put the files to scan in that folder. There is no target to type and no credential.

Asset produced: MultiscannerEndpoint. Credentials: none.

Why there is no path field. The scan container carries a source credential in its job file. A free-text file:// target would let a scan read that token and report it back as a finding, which defeats the point of giving the container exactly one secret. The folder is fixed, mounted read-only, and composed server-side.

Scan descriptor: scan_targets/filesystem.

10. Jenkins

A Jenkins instance's jobs and builds.

Asset produced: MultiscannerEndpoint. Credentials: Jenkins Username and Password, both optional. An exposed unauthenticated instance scans without a credential, and is itself a finding.

Scan descriptor: the URL.

11. Elasticsearch

An Elasticsearch cluster's indices and documents.

Asset produced: MultiscannerEndpoint. Credentials: Username, Password, API Key, Service Token, all optional. If the cluster is secured, set exactly one of: username+password, API key, or service token.

Validation rules

• Set at least one node or a Cloud ID.
• A Cloud ID must be in the <name>:<base64> form. RedAmon decodes it to recover the hidden host, because a Cloud ID that cannot be decoded presents no host for the egress guard to check while still reaching whatever it resolves to. An undecodable value is refused.

Scan descriptor: the node list, or the Cloud ID.

The engine's continuous "best effort scan" mode is deliberately not offered: it never finishes, so the run would never reach a terminal state and would hold its memory reservation forever.

12. Postman

Postman workspaces, collections and environments.

Asset produced: MultiscannerEndpoint. Credential: Secret Multiscanner Postman Token, mandatory.

Validation rules

• Set at least one workspace, collection or environment.

Scan descriptor: the workspaces, collections and environments, joined.

13. CircleCI

Asset produced: MultiscannerEndpoint. Credential: Secret Multiscanner CircleCI Token, mandatory.

No fields. The token defines the scan scope, so there is nothing else to configure. Add the source, set the key, start it.

14. Travis CI

Asset produced: MultiscannerEndpoint. Credential: Secret Multiscanner Travis CI Token, mandatory.

No fields. The token defines the scan scope.

Advanced shared options

These options exist on the project and are sent with every scan, but they have no control on the settings page: they ship with sensible defaults and are meant for tuning through the API or a preset rather than by hand. They are listed here so nothing about a run is invisible.

Two flags are always on and cannot be turned off:

• No self-update. The engine self-updates on startup, which fails outright on the container's read-only root filesystem and would silently replace the pinned, checksum-verified version.
• Fail on scan errors. The engine exits 0 even when a scan wholly failed: a nonexistent path, an unreachable host or a rejected token all still exit 0. Without this flag, a run that never reached its target would be reported as a clean result, and "0 findings" would read as "no secrets here".

Step 3: run the scans

Open the Red Zone and click Other Scans in the toolbar. The Secret Multiscanner card lists one row per configured source, in the order the sources were added.

Unlike GitHub Secret Hunt, this scanner does not require a recon run first. A source can be started on a brand-new project.

Each source row carries:

Card-level controls:

Logs. Each source streams its own container output live, with three phases: Preparing, Scanning, Complete. Credentials are redacted before the logs leave the orchestrator, by value rather than by flag name, so a token spliced into a clone URL is caught too.

Parallelism. Start one source, then another; they run at the same time. Starting the same source twice is refused while the first run is live, and the one-profile-per-source rule is a database constraint rather than a convention.

PAUSE ALL. The Red Zone's emergency button has no pause for this scanner: it stops every live source instead. There is no pause or resume for multiscanner runs.

Queue and history. Runs appear in the Scan Timeline's Scan queue and Run history. A queued job's fingerprint covers the shared options and the source profile's own config, so re-pointing a queued Docker scan at a different namespace invalidates the job and it has to be re-confirmed before it dispatches. Scheduling covers the full recon pipeline only: multiscanner sources are started by hand or enqueued.

Understanding results

Graph model

Findings land in the Neo4j graph as one scan node per project and source:

Domain ──HAS_MULTISCANNER_SCAN──> MultiscannerScan     (one per project + source)
MultiscannerScan ──HAS_ASSET──> <asset node>
<asset node> ──HAS_FINDING──> MultiscannerFinding

Asset nodes are grouped by shape, not one label per source, so the graph stays readable:

MultiscannerScan properties:

Asset nodes (whichever of the five labels applies) carry: id, name (the repository, image, model, bucket or endpoint), source, asset_kind, scan_id back to the scan node, and the user_id / project_id tenant keys.

MultiscannerFinding carries:

How a finding is labelled per source

The node drawer relabels the generic asset and location fields so they say what they actually are:

Where to see these nodes

Deduplication and re-runs

Findings are deduplicated per source, on source + asset + location + line + detector. The same secret found by two different sources stays two findings, because the second source's context is a separate fact.

Re-running a source replaces only that source's previous findings. The clear happens at ingest time, not at start time, so a run that fails to spawn leaves the last good results intact.

Security model

• Dirty / clean split. The scan container parses attacker-controlled bytes (a malicious image layer, a hostile repository) with exactly one source credential in its environment and nothing else: no Neo4j credentials, no scanner API key, no HTTP call back to the webapp. Writing to the graph is a separate, later step performed by the orchestrator once the scan process has exited.
• Container hardening. Isolated bridge network, all capabilities dropped, read-only root filesystem, non-root user.
• Credentials are never configuration. No source field may hold a secret. Keys live on your user settings, are selected per source at start time, and are injected as environment variables using the exact names the engine itself documents, so the binary reads them directly and the token never appears in the container's process table. A profile config is exported verbatim into project.json in the project export zip, so a write containing a credential-looking key is refused rather than silently stripped, with a message pointing at the right place to put it.
• Egress guard. Every operator-supplied host is resolved before the scan starts, and a target resolving to a private, loopback or cloud-metadata address is refused. The check is on the resolved IP, not the name, so es.acme.io pointing at 169.254.169.254 is caught. Unresolvable is a refusal, not a pass. An Elastic Cloud ID is decoded first so its hidden host is checked too.
• Scope guard. Where the project declares a scope or rules of engagement, the target is checked against it. For name-only targets (a Docker image reference, a GitHub org, a Hugging Face model) this is the only applicable check, and it composes with the egress guard rather than replacing it.
• Local targets are never typed. The three sources that read from disk take a name, not a path. The server composes the path under the read-only mount, and a name with a slash or .. is refused.
• Log redaction. Both the command echo and the streamed output are redacted by credential value, not by flag name, so a token embedded in a composed clone URL is caught as well.

Troubleshooting

Next steps

• GitHub Secret Hunting: the complementary public-internet sweep. It greps the GitHub Code Search API for target-related secrets leaked anywhere on GitHub, and does pattern matching only. Use it for breadth, and the Secret Multiscanner's GitHub source for depth on repositories you already know about.
• Supply Chain Scanning: malicious and vulnerable dependency detection, which is the other half of a repository audit.
• Red Zone: where the scans are started and the secrets table lives.
• Attack Surface Graph: the node and relationship reference.
• AI Agent Guide: the agent can query these findings and filter on validation status to focus on live credentials.