Safeguard.sh Documentation Center

Secrets Scanning

Find leaked credentials, API keys, and tokens in source code, container images, Git history, and vendor SBOMs.

Secrets Scanning

Secrets in source code and container images are one of the most common root causes of real breaches. Safeguard scans every asset in your inventory for known secret patterns, custom-defined patterns, and high-entropy anomalies — and verifies each finding against the issuing service before raising an alert.

What Gets Scanned

SurfaceMechanism
Source code (current HEAD)IDE extension, CLI, CI scan, continuous pull
Git historyDeep history scan on connect and on demand
Container images (all layers)Layer extraction + entropy + pattern matching
Packaged artifactsInside jars, wheels, gems, etc.
Build logsCI log tail ingestion with redaction at source
Vendor SBOMsSecrets leaking via build-provenance fields
Model weightsTokens and keys baked into fine-tunes (AI Security surface)

Detection Layers

Findings come from three overlapping layers:

  1. Issuer-specific patterns — curated regex + metadata for 200+ cloud providers, SaaS vendors, and identity providers. Examples: AWS Access Key ID, GitHub PAT, Slack Bot Token, Stripe Live Key, Twilio Auth Token, OpenAI API Key, Anthropic API Key.
  2. Generic patterns — RSA / EC / Ed25519 private keys, JWTs, Bearer tokens, OAuth refresh tokens, connection strings.
  3. Entropy / structural — high-entropy strings flagged by Eagle, with classification to reduce noise from hashes and UUIDs.

Verification — No False Positives at the API

For issuer-specific patterns, Safeguard verifies the secret by making a low-privilege API call to the issuer:

  • AWS keys → sts:GetCallerIdentity
  • GitHub PATs → /user
  • Stripe keys → /v1/balance (read-only)
  • Slack tokens → auth.test
  • OpenAI → /v1/models

Unverified findings are still raised but marked unverified. Verified findings mean the secret is live and exploitable right now.

You can disable verification per-issuer if outbound calls are restricted (air-gapped environments, for example).

Severity

  • Critical — verified, high-privilege credential (cloud admin, root token).
  • High — verified credential with lower privilege (read-only, CI scope).
  • Medium — unverified pattern match for a known issuer.
  • Low — generic pattern or entropy-based finding.

Custom Patterns

For internal tokens (company-issued JWTs, on-prem service credentials), add patterns via YAML:

custom_patterns:
  - id: acme-internal-api-key
    description: ACME internal service API key
    regex: 'acme_(?:prod|stage)_[A-Za-z0-9]{32}'
    severity: high
    verifier:
      type: http
      url: https://internal.acme.com/v1/verify-key
      method: POST
      header:
        Authorization: Bearer {{.secret}}
      expect:
        status: 200

Commit this to .safeguard/secrets.yaml or manage in the UI.

Allowlisting

Real secrets sometimes look like placeholders (example keys in documentation). Allowlist with three scopes:

  • Inline — a trailing # safeguard:allow <reason> comment on the line.
  • Path-based — glob patterns in .safeguard/secrets-allow.yaml (e.g., docs/**, *.test.js).
  • Issuer-based — allowlist all unverified findings for a specific issuer if you trust the pattern's FP rate.

Allowlists are tracked in audit — you see who added each entry and when.

Remediation Playbook

For every verified finding, Safeguard runs a playbook:

  1. Revoke — call the issuer's revoke API if available (AWS IAM, GitHub, Slack, Stripe, etc. supported).
  2. Rotate — open a PR with a placeholder and a TODO: rotate via Safeguard comment, or call your secret manager (AWS Secrets Manager, HashiCorp Vault, GCP Secret Manager, Azure Key Vault) to rotate.
  3. Purge from history — optional Git history rewrite with git-filter-repo or BFG, with a clear warning about the force-push implications.
  4. Notify — alert the owner and any dependent services.

Each step is gated; you decide whether the auto-revoke / auto-rotate runs headlessly or requires approval.

Pre-Push Prevention

The IDE extension and a git hook block secrets from being pushed in the first place:

safeguard install-hook --hook pre-push

The hook scans new commits locally before push. Same patterns as server-side. Zero latency when nothing is flagged; blocks the push with a clear reason when something is.

Policy Integration

Make secrets a blocker at commit / build / admission:

- id: no-verified-secrets
  condition: any(secrets, verified == true)
  effect: BLOCK

Reports

The Secrets dashboard shows:

  • Count and trend of secrets by issuer.
  • Time-to-revoke distribution.
  • Leaked-and-revoked vs. leaked-and-open stats.
  • Git history heatmap — which branches and authors had the most historical leaks.

API

safeguard secrets list --project my-api --verified true
safeguard secrets revoke --id <finding-id>
safeguard secrets rotate --id <finding-id> --secret-manager aws

On this page