Do not hard-code passwords, API keys, certificates, connection strings, or personal data in source code. Load secrets from protected configuration or secret storage, and use synthetic data in examples and tests. Scan repositories for embedded credentials, review commit history, and remove exposed values quickly if they are discovered, because source code is commonly copied and shared widely.
Stop secrets at the point of writing
The most reliable way to keep sensitive information out of source code is to treat code as an unsafe place for live secrets. Put passwords, API keys, certificates, tokens, and connection strings in protected configuration or secret storage, then have the application retrieve them at runtime. Use synthetic values in examples, tests, sample files, and documentation so developers never need real credentials to make the code work.
That separation matters because source code is copied into repositories, build systems, logs, code review tools, forks, and shared snippets far more widely than most teams expect. If a secret appears in code once, it often spreads into more places than the original file.
How leaks happen in normal development work
Secrets usually appear through convenience, not malice. Developers may paste a token into a test fixture, hard-code a connection string for a quick fix, or leave sample credentials in a config file that later becomes production-adjacent. Commit history then preserves the exposure even after the visible line is removed, which means the secret can remain recoverable long after the file looks clean.
Repository scanning is therefore part of prevention, not just cleanup. Search for embedded credentials before merge, scan historical commits and branches, and treat copied code samples, issue attachments, and paste fragments as the same risk class as the main source tree. When a secret is discovered, remove it quickly and assume any exposed value may need rotation.
Use cases and tests should be designed so that no one needs live production material to run them. That includes avoiding real personal data in fixtures and replacing live endpoints with masked or synthetic equivalents. Safe examples reduce both accidental disclosure and the temptation to reuse “temporary” credentials that later become permanent.
Build a workflow that makes exposure hard to repeat
Prevention works best when the developer experience makes the secure path easier than the unsafe one. Secret managers, environment injection, and managed configuration should be the default path for runtime values, while code review and automated checks catch anything that slips into the repository. The goal is not just to hide secrets, but to make accidental inclusion visibly unusual.
Teams should also decide what to do when a leak is found. A value in a public commit, build artifact, chat log, or copied snippet should trigger a fast decision on rotation, invalidation, and scope review. If the exposed value can authenticate to production, the response should move immediately from cleanup to blast-radius assessment.
Risk and Threat Considerations
Source-code leakage is dangerous because code often carries both direct secrets and clues that make follow-on compromise easier, such as environment names, service endpoints, and deployment patterns. A single exposed token can grant access to code, cloud services, or downstream systems, and a single hard-coded credential can become reusable across environments if teams copy it for convenience.
Failure mechanism: Developers embed live secrets in code or commit history, scanners miss the exposure, and an attacker or unauthorised insider reuses the credential before it is rotated.
Impact: The result can be repository access, cloud account compromise, data exposure, unauthorized changes, or a wider incident that persists because historical copies of the secret remain available in branches, forks, logs, or caches.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 addresses the attack surface, OWASP ASVS, CIS Controls v8 and NIST SP 800-53 Rev 5 set the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP ASVS | V9 — Self-contained Tokens | Protects token handling and storage in application code and tests. |
| Recommendation — Keep tokens out of source and inject them only through protected runtime mechanisms. | ||
| CIS Controls v8 | CIS-5 — Account Management | Supports controlling and rotating credentials exposed in code repositories. |
| Recommendation — Inventory and rotate exposed credentials before attackers can reuse them. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Covers lifecycle handling for secrets used to authenticate systems and users. |
| Recommendation — Manage authenticators so exposed secrets are replaced quickly and consistently. | ||
| ISO/IEC 27001:2022 | A.8.24 — Use of cryptography | Relevant because code should not contain recoverable secrets and sensitive values need protected handling. |
| Recommendation — Protect sensitive values with approved secret storage and strong handling controls. | ||
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | Directly addresses secrets embedded or exposed in source code and repositories. |
| Recommendation — Scan repositories for leaked secrets and remove exposed values immediately. | ||
Practitioner Guidance
What to verify: Check that the secure path is actually being used, not just documented. If developers can still paste real secrets into examples, local configs, or test data without friction, the control is weak even if scanning exists.
Decision rule: If a secret is needed to run code, it should be retrieved at runtime from an approved secret store or injected by the environment, never embedded in the repository. If the value has already appeared in source or history, rotate it first and then clean the codebase.
Common mistake: Teams often delete the visible line and stop there. Historical commits, pull request discussions, CI logs, and copied snippets can still preserve the secret, so cleanup must include all places the value may have propagated.
Practitioner takeaway: Treat source control as a distribution channel, not a vault: keep live secrets out of code, assume anything committed may already be shared, and make rotation part of the response whenever exposure is discovered.
Related resources from NHI Mgmt Group
- Guide: CWE Top 25 Guide
- How can developers prevent sensitive information from appearing in test code?
- How do developers prevent inserting sensitive information into debugging code?
- How should Android developers prevent overlay attacks on screens that collect sensitive information?
- How do developers prevent inserting sensitive information into sent data?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 18, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org