하드코딩된 시크릿 패턴

Secret formats are public knowledge. Stripe documents them, AWS documents them, GitHub documents them, OpenAI documents them — the prefixes and shapes are part of the API spec, intentionally distinguishable so SDKs can validate input early. The same documentation that helps developers also helps attackers and the dozens of automated scrapers continuously scanning the public web for leaked credentials. A leaked key is instantly recognizable: `sk_live_` prefix means Stripe live secret, `AKIA` prefix means AWS access key, `ghp_` prefix means GitHub personal access token, `sk-` prefix with the right length means an OpenAI key. The pattern is the punishment.

Each cloud and SaaS uses a distinct secret format with stable enough properties to support high-precision regex matching. Stripe: `sk_live_[a-zA-Z0-9]{24,99}` for live secrets, `pk_live_[…]` for publishable, `whsec_[…]` for webhook secrets. AWS: `AKIA[0-9A-Z]{16}` for IAM access key IDs, `ASIA` prefix for STS temporary credentials. GitHub: `ghp_` for classic PATs, `gho_` for OAuth tokens, `ghu_` for user-to-server, `ghs_` for server-to-server, `ghr_` for refresh. OpenAI: `sk-[a-zA-Z0-9]{48}` (varies by tier). Slack: `xox[baprs]-[…]` family. Supabase service-role JWTs have a recognizable header structure. We curate ~18 patterns covering the most common, highest-impact services.

Tracks the leaked secret. Stripe live keys are billing takeover — refund operations, fraudulent charges, customer data exposure. AWS keys are full cloud access depending on role policy; permissive roles are RCE-class. OpenAI keys are bill-driving abuse (attackers run inference on your account until your spending limits trigger). GitHub PATs with repo scope are source code, CI secrets, and often the keys-to-everything-else. Service-role tokens (Supabase, Firebase) bypass RLS entirely and grant full database access. Each is potentially business-ending depending on what's behind it.

Don't hardcode secrets in client code. Use environment variables, scoped to server-side only — `process.env.STRIPE_SECRET_KEY` should not be referenced in any file that ships to the client bundle. Mark server-only files with `import 'server-only'` (Next.js) or equivalent so a stray client import becomes a build error. Add CI scanners — gitleaks pre-commit, trufflehog in PRs, FixVibe's own bundle scanner pre-deploy — and treat any positive as a deployment-blocking event. Rotate any secret that has ever appeared in a public response, regardless of how briefly. Use secret-management tooling (Vercel env vars, AWS Secrets Manager, HashiCorp Vault, Doppler, 1Password Secrets Automation) so secrets aren't committed to source in the first place. As a final layer, scope every credential to the minimum permissions and shortest lifetime your use case allows — so even when leaks happen, the damage is contained.

The fix isn't a tool, it's the mental model: there are public secrets and there are private secrets, and the rules are different. Treat the client bundle as a publication channel.