How to Remove Secrets from Code Before Scanning

Before scanning source code, remove credentials such as API keys, passwords, and private tokens so they are not exposed to a scanner or stored in a report.

The tricky part is that deleting a secret from the current file may not remove it from Git history, logs, or copied artifacts.

What counts as a secret in source code?

A secret is sensitive information that can grant access to an account, service, system, or data.

Common examples include cloud access keys, database passwords, private keys, OAuth client secrets, session-signing keys, and personal access tokens.

Connection strings and configuration files may contain several secrets at once.

Look beyond files named .env.

Credentials can appear in source files, notebooks, test fixtures, shell scripts, CI/CD configuration, container files, documentation, sample requests, and commit messages.

A value that looks like a placeholder may still be active if it was copied from a real environment.

How to remove secrets from code before scanning

1. Identify what may be exposed. Search the project for credential names and suspicious values, including terms such as API_KEY, password, token, secret, and private_key.
   
   Also check configuration files and recent changes.
   
   Automated secret-detection tools can help find patterns, but review the matches because legitimate examples and false positives are possible.
2. Revoke or rotate any real credential. If a live key or password has entered the repository, treat it as compromised—even if the repository is private or the value was quickly deleted.
   
   Revoke it with the provider, issue a replacement, and check relevant access logs when available.
   
   Removing the visible text does not invalidate the credential.
3. Replace hard-coded values with configuration. Read secrets from environment variables or an approved secrets manager at runtime.
   
   Keep local values in an ignored file such as .env, and commit a template like .env.example containing variable names and clearly fake placeholders.
   
   Verify the template has no working credentials.
4. Check the scan copy and its boundaries. Prepare a clean working tree or sanitized copy containing only the files needed for the scan.
   
   Exclude local environment files, build outputs, caches, logs, backups, and unrelated repositories.
   
   Check archive contents before uploading: excluding a file from a command does not help if it was already included in a ZIP or other bundle.
5. Review the result before sharing it. Scan reports, debug output, command history, and support tickets can reproduce snippets or file paths.
   
   Limit access to reports and redact any exposed value before sending results to another person or service.

Why deleting a secret from a file may not be enough

Git records snapshots across commits.

If a credential was committed, a later edit removes it from the current version but may leave it in earlier commits, branches, tags, forks, or clones.

The credential should still be rotated.

If you also need to remove the value from repository history, follow the hosting provider’s and Git tool’s documented history-rewriting process, coordinate with collaborators, and account for existing clones.

History rewriting can change commit identifiers and disrupt shared work.

It is a separate cleanup step from sanitizing a scan copy.

Check pull requests, issue comments, CI logs, package artifacts, and deployment logs too; those may retain copies outside Git history.

Use secret scanning and code scanning for different jobs

Secret scanning looks for credentials and other sensitive values.

Source-code similarity tools compare code with other code or reference collections.

AI authorship classifiers estimate whether text may have been generated by an AI system.

These checks address different questions, so one does not replace another.

An AI-writing score is not proof of who authored code or whether misconduct occurred.

Site context matters: Turnitin says its AI writing model does not reliably detect code, and its writing report should not be confused with source-code similarity analysis.

Policies and review procedures vary between organizations and institutions.

If your goal is to check code similarity, use the relevant source-code process and understand what material it requires before submitting files.

Codespy is an external source-code detection option; review its current documentation, data handling terms, and submission requirements directly.

A product mention is not a test result or endorsement, and no detector score alone establishes authorship or wrongdoing.

A practical pre-scan checklist

• Search tracked files, untracked files, configuration, notebooks, and recent changes for credentials.
• Revoke and replace any live credential that was exposed.
• Move required secrets into environment variables or an approved secrets manager.
• Confirm ignored files, archives, and scan inputs do not contain local credentials or unrelated data.
• Decide whether repository history or external logs also need cleanup.
• Read the scanner’s current requirements and privacy terms, then review any report before sharing it.

A careful preparation pass reduces the chance of disclosing a credential while keeping the scan focused on the code you intend to review.

If you find an exposed key, prioritize invalidating it; deleting its text is only one part of remediation.