Secrets and API keys: why they leak and how secret managers and scanning work

Microsoft and AWS describe two ways to store API keys securely: avoid stored keys where the platform allows it, and keep the rest in a secret manager rather than in code. Knowing how to store API keys securely matters because a single leaked key can give someone the same access as the application that owns it. Secrets are the passwords of software: API keys, database connection strings, access keys, tokens and certificates. This guide explains what secrets are, why keys written into code are risky, how secret managers such as Azure Key Vault and AWS Secrets Manager work, why rotation matters, and how GitHub’s secret scanning catches keys in repositories.

Why it matters

People sign in with a password and MFA. Applications usually authenticate with a secret alone, with no second factor. Whoever holds the secret can usually use it.

The ACSC’s Cloud computing security for tenants guidance lists, among its general mitigations, protecting authentication credentials, for example “avoid exposing Application Programming Interface (API) authentication keys”. AWS’s Secrets Manager documentation says storing credentials in Secrets Manager rather than hard-coding them “helps avoid possible compromise by anyone who can inspect your application or the components.”

What counts as a secret

• API keys for payment, email, mapping or AI services
• Cloud access keys, such as AWS access key IDs and secret access keys, or Azure storage account keys
• Database connection strings that include a username and password
• Tokens such as OAuth tokens and personal access tokens
• Certificates and private keys

Configuration that isn’t sensitive is different. Microsoft’s Key Vault guidance says not to store configuration data such as IP addresses, service names and feature flags in Key Vault, and points to Azure App Configuration for that.

How keys end up exposed

• Hardcoded in source code and pushed to a repository, sometimes a public one.
• Committed and then “deleted”. GitHub notes that secret scanning checks the full Git history on all branches, which is where old credentials often sit.
• Copied into config files, chat messages, tickets or wikis. GitHub’s secret scanning also covers issues, pull requests, Discussions and wikis for this reason.
• Long-lived and never changed. Microsoft notes that secrets stored in application memory or configuration files “persist for the entire application lifecycle, increasing exposure risk.”
• Over-privileged. A key with administrator rights does more damage than a read-only one. See cloud identity and access management.

How to avoid stored secrets altogether

The safest secret is one that doesn’t exist. Cloud platforms increasingly let workloads authenticate without stored credentials.

• Azure managed identities: Microsoft says managed identities let applications obtain Microsoft Entra tokens “without having to manage any credentials”, that “credentials aren’t even accessible to you”, and that managed identity “replaces secrets such as access keys or passwords.”
• AWS IAM roles: AWS’s IAM best practices describe workloads using IAM roles to obtain temporary credentials, and human users signing in through federation for temporary credentials, rather than long-term access keys.
• AWS root user: AWS strongly recommends not creating access keys for the root user, because it has full access to all services and resources, including billing.

How secret managers work

A secret manager is a central, access-controlled store that applications ask for credentials at runtime, instead of carrying them in their code.

AWS Secrets Manager. AWS describes it as a way to “manage, retrieve, and rotate” database credentials, API keys, OAuth tokens and other secrets, and to “replace hard-coded credentials with a runtime call to the Secrets Manager service.” Because the credential no longer lives in the application, AWS says rotating it “no longer requires updating your applications and deploying changes.”

Azure Key Vault. Microsoft describes Key Vault secrets as storing “sensitive application credentials like passwords, connection strings, and access keys.” Its best practices include:

• storing compound credentials as a connection string or JSON object, with metadata such as rotation schedule and owner in tags rather than in the value
• caching secrets in the application to reduce calls and avoid throttling, and refreshing the cache when secrets rotate
• logging all secret access operations, and setting Azure Monitor alerts for suspicious access patterns or failed authentication
• periodically auditing who has access to secrets and removing unnecessary permissions.

A common pairing in Azure is a managed identity that is allowed to read specific Key Vault secrets, so the application holds no credential at all.

How rotation works

Rotation means replacing a secret with a new value on a schedule, and updating the service that accepts it.

• AWS describes rotation as updating “the credentials in both the secret and the database or service”, and lists managed rotation (no Lambda function), managed external secrets rotation for partner-held secrets, and rotation by a Lambda function for other secrets.
• Microsoft’s Key Vault guidance says shorter rotation intervals, “for example, 60-90 days”, reduce exposure risk, and describes automating rotation and using dual credentials so rotation doesn’t cause downtime.
• AWS’s IAM best practices describe rotating long-term access keys regularly where they’re unavoidable, using “last used” information to find keys to rotate or remove.

Scanning repositories with GitHub secret scanning

GitHub describes secret scanning as automatically detecting credential leaks “so you can secure them before they’re exploited.”

• Availability: GitHub says secret scanning “runs automatically for free” on public repositories. For organisation-owned private and internal repositories, it requires GitHub Secret Protection on GitHub Team or GitHub Enterprise Cloud.
• Partner alerts: when GitHub finds a secret from a partner provider, it notifies that provider “so they can take action, such as revoking the credential.”
• Push protection: GitHub says push protection blocks pushes that contain likely secrets “before they reach your repository”. For personal accounts on GitHub.com it is on by default for pushes to public repositories. Repository-level push protection requires GitHub Secret Protection and is off by default.
• Bypasses: by default, anyone with write access can bypass push protection by giving a reason, which creates an alert and an audit log entry.

What GitHub says to do when a secret is found

Based on GitHub’s documentation (checked October 2026). GitHub’s guide to remediating a leaked secret has the latest steps.

1. Revoke the secret with its provider. GitHub calls this the most important remediation step, and its secret scanning overview says: “When you receive an alert, rotate the affected credential immediately to prevent unauthorized access.”
2. Generate a new secret, if one is needed, to replace the revoked one.
3. Update every application and service that uses it, then test that they still work. Reading the new value from a secret manager avoids repeating the problem.
4. Review GitHub’s audit logs and the provider’s logs for any use of the old secret.
5. Then decide whether to remove the secret from the Git history. GitHub says this “is time-intensive and often unnecessary if you’ve already revoked the credential”, and that rewriting history is disruptive.

A fictional example

Sam, a student building a weather app, pushes code to a public repository with a mapping API key in a config file. Push protection blocks the push and explains why. Sam removes the key, creates a new one in the provider’s console, and stores it as an environment secret read at runtime. Later, at his part-time IT job at hardware.example, Sam sees the same idea at scale: the web app’s database password lives in Azure Key Vault, the app reads it with a managed identity, and the vault’s access log feeds an alert, as described in cloud logging and monitoring.

Things to watch for

• “Private” repositories. Private reduces exposure but doesn’t remove it; collaborators, forks and backups can all hold a copy.
• Deleting the commit instead of rotating. GitHub’s documentation puts rotation first.
• Storage account keys. Microsoft notes anyone with the key can create shared access signatures without the owner knowing; see cloud storage permissions.
• Secrets in AI prompts and chat tools. Pasting a key into a chat or assistant is another copy outside the vault; see AI assistants and confidential data.
• Generic alerts. GitHub notes its generic secret alerts can have a higher false-positive rate, so each one needs a look before action.

Common questions

How do I store API keys securely?

Cloud providers describe two approaches. First, avoid stored keys entirely where possible, using managed identities in Azure or IAM roles with temporary credentials in AWS. Second, where a secret is unavoidable, keep it in a secret manager such as Azure Key Vault or AWS Secrets Manager, which applications call at runtime instead of carrying the key in their code. Giving each key only the access it needs limits the damage if it leaks. See how secret managers work.

What do I do if I’ve accidentally pushed an API key to GitHub?

GitHub calls revoking the secret with its provider the most important remediation step, and says to rotate the affected credential immediately to prevent unauthorised access. GitHub’s guide then describes generating a replacement if needed, updating every application and service that uses it, and reviewing GitHub’s and the provider’s logs for any use of the old key. For partner secrets, GitHub may also notify the provider. See what GitHub says to do when a secret is found.

Is deleting the commit enough after leaking a key?

No, according to GitHub’s documentation, which puts revoking and rotating the key first. GitHub says secret scanning checks the full Git history on all branches, so a key that was committed and later deleted can still be found. It also says removing a secret from Git history is time-intensive and often unnecessary once the credential has been revoked, and that rewriting history is disruptive. See how keys end up exposed.

Is GitHub secret scanning free?

For public repositories, yes. GitHub says secret scanning runs automatically for free on public repositories, and push protection is on by default for personal accounts pushing to public repositories. Private and internal repositories owned by organisations need GitHub Secret Protection on a GitHub Team or Enterprise Cloud plan, and repository-level push protection is off by default. See scanning repositories with GitHub secret scanning.

How often should API keys be rotated?

It depends on the system. Microsoft’s Key Vault guidance gives 60 to 90 days as an example of a shorter interval that reduces exposure risk, and describes automating rotation and using dual credentials so rotation doesn’t cause downtime. AWS describes automated rotation in Secrets Manager so applications don’t need redeploying, and rotating unavoidable long-term access keys regularly. See how rotation works.

Is it safe to keep API keys in a private repository?

A private repository reduces exposure but doesn’t remove it, because collaborators, forks and backups can all hold a copy. Microsoft also notes that secrets kept in configuration files persist for the entire application lifecycle, increasing exposure risk. The approaches the providers describe keep keys out of code entirely, in a secret manager or replaced by managed identities and IAM roles. See how to avoid stored secrets altogether.

Where to get official help

• The ACSC for cloud security guidance, ReportCyber and the 24/7 hotline (1300 CYBER1, 1300 292 371).
• Microsoft Learn: securing Azure Key Vault secrets.
• AWS: rotating Secrets Manager secrets.
• GitHub: about secret scanning.