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

Liked this post? Share it:

Related posts

Related posts appear on the live page

VIEW ALL RESEARCH ->

PAGE CONTENTS

Contents appear on the live page

// 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: