Secrets

Catch potential credentials in the change you are about to share, without repeating them in the scan report.

Check ID: secrets. Engine: Secretlint 13.0.4 with its recommended preset 13.0.4, verified against the Zedbee 0.1.0 source snapshot on September 7, 2026.

Built-in check

Check for secrets before sharing a change

Swarm runs Secretlint locally with a fixed managed preset. It looks for patterns that may be credentials; a match needs review and is not proof that the credential is valid or active.

The recommended and thorough profiles enable this check at error severity. fast leaves it off. The example makes the recommended policy explicit; adding it is not required if that profile already supplies the settings you want.

The check supports severity and timing, not custom Secretlint plugins or rule configuration. Swarm does not load .secretlintrc or executable project configuration.

Keep policy in the repository-root .zedbeerc.jsonc. Stage settings updates for the next local scan; commit and push them for a CI run that checks out the updated commit.

When settings updates take effect

{
  "schemaVersion": 1,
  "profile": "recommended",
  "checks": {
    "secrets": {
      "severity": "error",
      "when": "relevant"
    }
  }
}

Coverage

Which files are inspected?

Secret scanning uses changed files from the selected Git snapshots, not whatever is open in your editor. It is not limited to JavaScript and TypeScript source extensions.

Secret scanning input boundaries
Input	Behavior
Ordinary local scan	Inspects changed files in the exact staged index and their baseline versions where present. Later unstaged edits do not replace the staged content.
CI scan with --base	Uses changed files between the merge-base commit and committed HEAD. Working-tree edits do not replace either snapshot.
Regular UTF-8 text files	Changed files up to 1 MiB are eligible. Secretlint examines the selected file content, not only a list of added lines.
Oversized or invalid UTF-8 input	Files that exceed the size limit or cannot be safely decoded produce an incomplete check, not a clean result.
Binary or non-regular files	This is not a binary secret scanner. NUL-containing content is skipped by the text collector; unsafe or non-regular selected files can make analysis incomplete.
Unchanged files and full Git history	Not a repository-wide credential inventory or a history scan. Setting timing to always does not expand this check beyond changed files.

Swarm compares baseline and target observations before attributing findings to your change. Replacing a secret with a different value at the same rule and location can still be recognized as a change; the replacement is not assumed to be existing debt just because it occupies the same position.

How findings are attributed to your change

Data handling

The report points to the secret, not its value

Secretlint receives the selected text in the local process. Swarm reduces its results to rule and location metadata with a generic message, rather than carrying the matched value or Secretlint’s raw message into the finding.

Secret finding content stays redacted in terminal output, JSON, SARIF, and source excerpts, including when ordinary source excerpts are enabled. Use the reported file and location to inspect the value locally; do not paste credentials into an issue or chat to ask about a finding.

To distinguish replacements, Swarm uses a temporary keyed comparison of the matched source range. The key and comparison digest are not rendered, cached, or persisted. Secretlint observations are not stored in the scan cache.

The secrets check does not send credentials to an online validation service. Other enabled checks and CLI update notifications have their own network behavior; local secret scanning does not mean every CLI operation is offline.

Review the scanner’s security boundaries

npx zedbee checks
npx zedbee scan --format json > zedbee-report.json

Act on a finding

Remove the credential, not just the warning

Inspect the reported location privately and decide whether it contains a real credential or a harmless test value. For a real credential, remove the literal from the code and use a safe reference to your runtime secret storage. The example reads a value supplied by the environment; it does not store the credential in the repository.

Review your changes, stage the affected files, and scan again. Editing a working file without staging it leaves the old value in the next ordinary scan’s target. zedbee fix does not automatically repair secret findings.

If the match is a false positive, review the rule and your repository policy before changing scope or severity. warn makes findings non-blocking, while off disables the check; neither proves the value is harmless.

Removing a secret does not revoke it.

Rotate or revoke a real exposed credential with its provider. Removing it from the current change does not erase it from previous commits, logs, or copies. Use a separate history scan when you need to investigate past exposure.

const token = process.env.SERVICE_TOKEN;
if (!token) {
  throw new Error("SERVICE_TOKEN is required");
}

Troubleshooting

Resolve incomplete inputs before trusting the result

SECRET_FILE_TOO_LARGE means a selected file exceeds the 1 MiB safety limit. SECRET_FILE_INVALID_UTF8 means the text could not be decoded safely. SECRET_FILE_UNSAFE points to a selected file that could not be read as a safe regular file.

Use the reported path to correct the input, then stage the corrected version for a local scan. In CI, commit and push the correction. Do not treat an unreadable file as proof that it contains no credentials.

For SECRETLINT_ANALYSIS_FAILED, run zedbee doctor, review the diagnostic, and retry with an updated installation if necessary. Exit code 2 represents incomplete required analysis, not a clean scan.

npx zedbee doctor
git diff --cached --stat
npx zedbee scan