Securing API Keys

An API key names a workspace and a project. Anything holding it can install through the proxy as that project, so the practices below are mostly about keeping it in one place and making it cheap to replace.

Keep keys out of source control

Use environment variables or a secret manager, and commit only configuration that references them. Every ecosystem page shows the committable form.

The files that tend to end up carrying a literal key:

• .npmrc with _authToken set to the key rather than ${SHIELDEDSTACK_API_KEY}
• nuget.config with ClearTextPassword
• pip.conf and pip.ini, where the credential is inside the index URL
• .bundle/config, when Bundler credentials were set without --global
• Cargo’s credentials.toml
• .env files of every description

Add them to .gitignore before the first commit, not after the first leak.

Rotate deliberately

Create the new key, roll it out, then revoke the old one. Because several keys can share a project name, rotation does not interrupt tracking or split a project’s history.

Revoking a key does not delete data. Historical usage stays attributed to the project.

Scope keys so revocation is cheap

Separate keys per environment, per project, or per pipeline mean a leaked key can be revoked without stopping everyone else’s builds, and the request log says which pipeline a request came from.

Protect keys in CI

Use the platform’s secret store: GitHub Secrets, Azure Key Vault, AWS Secrets Manager, or your own vault. Mask the value in logs, inject it only into restore steps, and never echo an effective package-manager URL, since in several ecosystems the credential is part of the URL.

Review periodically

• Audit who holds keys, and revoke unused ones.
• Watch the Control Plane for alerts on packages you already have.
• Re-read the workspace’s package filters, since a rule added during an incident often outlives its reason.