[fernando-mendoza]

What

Adds a Secret Scan workflow that runs gitleaks on every pull request into main and fails the check when it finds a key.

• .github/workflows/secret-scan.yml: pull_request → main, permissions: contents: read, actions/checkout@v7 with fetch-depth: 0.
• .gitleaks.toml: gitleaks' default rules plus a stellar-secret-seed rule (S + 55 base32 chars), which the defaults don't cover. Every allowlist entry is narrow and commented.
• CONTRIBUTING.md: one line saying what to do when the check fires (rotate, remove from the branch, or add a narrow commented allowlist entry for a real false positive).

Why / design choices

• The gitleaks CLI, not gitleaks/gitleaks-action. The action needs a paid GITLEAKS_LICENSE for repos owned by an organization. The workflow downloads gitleaks 8.28.0 and checks its SHA-256 before running it.
• Scans only the PR's commits (base.sha..head.sha), so old history doesn't block new PRs. Rewriting history is out of scope, per the issue.
• Allowlist:
  • the SXXXX… placeholder seed in the docs
  • inside examples/ only, the one published testnet test vector in examples/rust-x402/tests/integration.rs. Any other seed in examples/ still fails.
  • Stellar public G… account IDs, which the default generic-api-key rule flags in test fixtures. A G… strkey is always public.
  • one minified identifier (hasV2Preconditions) in actions/verify-audit-cid/dist/index.js. It requires both the path and the value to match.
  • Note: gitleaks 8.28 ignores targetRules for extended default rules, so the G… entry is global.

How tested

• gitleaks dir on the current main tree with this config: no leaks found. Without the config, it finds 12, all of them false positives covered above.
• gitleaks git over the full history: one finding, a Stellar seed in packages/cli/test/pay-serve.test.js added in 050104e. It has since been removed from the tree. PR-range scans don't see it, but I'm flagging it here.
• Throwaway local commits scanned over the commit range:
  • fail: an AWS key pair, a random Stellar seed outside examples/, a new random seed inside examples/, an RSA private key, the allowlisted test vector outside examples/, hasV2Preconditions outside dist/, a GitHub PAT inside examples/
  • pass: clean commit, the placeholder seed, a G… address, the test vector inside examples/
  • exit code is 1 on findings and 0 when clean
• actionlint 1.7.7: clean.
• Failing run on a fake key (a throwaway PR inside my fork, now closed and the branch deleted): https://github.com/fernando-mendoza/nirium/actions/runs/41578134581. It found stellar-secret-seed and aws-access-token in packages/sdk/tmp/leak.env and exited 1.

To make this actually block merges, Secret Scan / gitleaks needs to be added as a required status check in branch protection. That's a maintainer setting.

Closes #224

[Eras256]

@fernando-mendoza one more thing on this PR, unrelated to the gitleaks setup itself: the gitleaks scan (running it locally against full history, not just this PR's diff) turned up a real Stellar secret seed committed in 050104e, packages/cli/test/pay-serve.test.js. It's a valid secret, not a placeholder - it derives to GAKBHMZEWVVW6ST7D6GNR3LTDNYTMQT3K64X2D7BN35QWJ2T7IA5AXCI, a real funded testnet account (~9,950 XLM, ~88 USDC, last activity 2026-08-24).

Do you recognize this account? If it's one of ours, please rotate it. If it's not, no action needed on our end - just flagging since it's sitting in our git history either way.

(Marked gitleaks as a required check on main now, separately - new commits can't reintroduce this class of issue going forward.)

[Eras256]

Checks green, scoped to its own issue, no touch on auth/secrets/CORS. Merging.