Nexus Void Research
Secret Scanning, Hardcoded Secrets, Credential Leak, AppSec, ARGUS, DevSecOps
How to Find and Fix Hardcoded Secrets in Your Code
How to find hardcoded secrets in code: where keys and tokens hide, how to detect them in pull requests, and how to safely remediate a leaked secret.
To find hardcoded secrets in code, you scan your repositories and every new pull request for patterns that look like credentials, API keys, tokens, and private keys, then verify and remediate the real ones by rotating the exposed secret and moving it into a secrets manager. Hardcoded secrets are tracked as CWE-798, and they are among the most common and most damaging findings because a single leaked key can hand an attacker your cloud account, database, or a third-party service. The critical detail: once a secret reaches Git history, deleting the line is not enough, because the value stays in history and must be rotated.
Understanding how to find hardcoded secrets matters because they leak constantly and quietly. Keys end up in source files, config, test fixtures, notebooks, CI logs, and commit history, and they are especially common in code produced quickly by AI coding assistants. Attackers actively scan public and breached repositories for them, so detection speed is what limits the damage.
Where do hardcoded secrets usually hide?
Not just in obvious .env files. The recurring hiding spots are source files with an API key pasted for a quick test, configuration and infrastructure-as-code files, test fixtures and mock data, Jupyter notebooks, CI/CD logs that echo variables, and, most dangerously, old commits in Git history that a later cleanup never removed. Any place a developer touched a credential to make something work is a candidate.
Location | Example secret |
|---|---|
Source and config files | Cloud or SaaS API keys |
Infrastructure as code | Database passwords, tokens |
Test fixtures | Sandbox keys reused in prod |
Git history | Rotated-looking but still-live keys |
CI/CD logs | Environment variables echoed to output |
How do you detect hardcoded secrets in a pull request?
Run secret scanning on every commit and pull request, not just as a periodic sweep, so a key is caught before it ever merges. Good scanners combine high-signal regex patterns for known key formats with entropy analysis to catch generic tokens, and they check the diff so review happens at the moment of introduction. Catching a secret in the pull request is the difference between rotating one key quietly and cleaning it out of history after it has already shipped.
How do you remediate a leaked secret safely?
Assume any committed secret is compromised. Rotate it first, immediately, at the provider, because revoking the exposed value is what actually stops the risk. Then remove it from code and load it from a secrets manager or environment injection instead, and if it was in a public or shared repo, purge it from Git history. ARGUS scans every pull request for hardcoded secrets alongside vulnerable dependencies and insecure code, and opens the fix as a pull request, so secrets are caught at introduction rather than discovered after a breach. Rotation at the provider is still a human step, because only you can safely cycle a production credential.
Frequently asked questions
Why is deleting the line not enough? Because Git keeps history. The secret remains retrievable in earlier commits, so it must be rotated at the provider and, ideally, purged from history.
What is the difference between secret scanning and SAST? Secret scanning looks for credentials committed into code; SAST looks for insecure code patterns. Both belong in the pull request, and many tools run them together.
Do AI coding assistants increase secret leaks? Yes, in practice. Fast, high-volume generation and quick test snippets raise the chance a key gets pasted into code, which is why per-pull-request scanning matters more as AI-authored code grows.
Our read
Hardcoded secrets are the cheapest breach an attacker can hope for and the cheapest to prevent, which is why catching them at the pull request is one of the highest-return controls a startup can add. The failure mode is treating a found secret as a code cleanup instead of an incident: the moment a credential is committed, it should be considered burned and rotated. Detection in the diff plus disciplined rotation, rather than a quarterly sweep, is the verifiable-by-design approach, and it keeps a leaked key from becoming a leaked account.
Weakness definition per CWE-798; remediation guidance per the OWASP Secrets Management Cheat Sheet. Sources linked above.
Related: CTO guide to securing a startup codebase and how to secure third-party API integrations.
DATA SOURCES
OWASP Secrets Management Cheat Sheet — https://cheatsheetseries.owasp.org/cheatsheets/Secrets_Management_Cheat_Sheet.html ; CWE-798 Use of Hard-coded Credentials — https://cwe.mitre.org/data/definitions/798.html ; GitHub Secret Scanning docs — https://docs.github.com/code-security
PAGE CONTENTS
// FROM THE LAB
Pentesting is easy and affordable now.
Continuous VAPT you can run every month, with a report built for AI-built apps.
RUN A VAPT ->
// CYBER NETWORK
Shape the next analysis.
A curated network of security practitioners who help set our research agenda. By application.
APPLY TO JOIN ->
Get new research first
We publish original analysis and experiments on how attackers actually move. Follow along:
RECENT POSTS
VIEW ALL RESEARCH ->