generation API secret scanning: check repositories and shipped artifacts

A server-side key can leak through more than a committed source file. Build outputs, source maps, CI artifacts, screenshots, and copied request diagnostics are separate exposure paths. Establish a scanning and response process that covers what developers edit and what users actually receive. Do not assume a scanner recognizes a Genace-specific token pattern unless that capability is documented.

Inventory the exposure surfaces

Review environment templates, frontend configuration prefixes, Docker build contexts, generated static files, test fixtures, and logging code. A populated environment file should not enter Git or a public asset directory. A private variable name alone is not a secret, so distinguish references such as GENACE_API_KEY from actual credential values.

Use your repository platform’s supported secret scanning and push protection features where available, with custom patterns or approved local tooling for gaps. Include historical branches and artifacts according to your retention and access policy. A clean current working tree does not establish that an older revision never exposed a token.

source checks: tracked files, staged changes, environment templates
history checks: supported repository scanning across relevant refs
artifact checks: browser bundles, source maps, container build context
runtime checks: logs, traces, CI attachments, support diagnostics
response: identify owner, rotate credential, update consumers, verify

This checklist is an application operations process, not a Genace secret scanning API. Assign ownership and make findings actionable rather than producing an unreviewed list of matching strings.

Test detection without using a real credential

Create a unique synthetic marker for your local pipeline test and place it in a fixture that should be blocked from public output. Confirm the scanner or artifact check catches that marker and that reporting redacts its value appropriately. Remove the fixture through your normal review process after the test.

Do not paste a real production key into a command line, CI variable echo, or public issue to see whether detection works. If your tooling needs an exact-match check for an existing secret, use a protected implementation that reports only file identity and finding category, never the secret itself.

Treat confirmed exposure as a credential event

Deleting a leaked line does not revoke access already granted by that value. Rotate or revoke the credential using the account’s supported management controls, update every inventoried consumer, and verify the replacement with read-only requests. Preserve known job IDs during the rollout so observers do not submit replacements when authentication temporarily fails.

Review whether signed media URLs or prompts were exposed too. Their response may involve access expiry, storage policy, or incident handling distinct from bearer key rotation. Avoid broad raw-payload logging that recreates the same exposure in another system.

Acceptance criteria

Confirm synthetic leakage is detected in source and in the actual browser artifact pipeline. Verify confirmed findings have an owner and remediation record. After a rotation, check that all consumers load the new configuration and the retired credential is no longer accepted. No paid generation is required to validate this operational path.

See key rotation, environment handling, and log redaction.

Continue with security

• generation browser proxy CSRF: protect cookie-authenticated submission routes
• generation API egress allowlist: separate API traffic from media retrieval
• generation API key rotation: migrate consumers without test renders
• Browse all security guides