Migrate a Codebase Off Hardcoded Secrets

Hardcoded secrets are the single most common finding you'll meet in this entire phase — and the remediation is a project, not a one-line fix. It involves finding every secret (including the ones buried in git history), rotating them all (they must be assumed compromised), moving them into a managed store, changing how the application authenticates so it has no bootstrap secret of its own, and preventing recurrence. Do it in the wrong order and you either break production or leave live credentials exposed.

In this exercise you'll plan the migration for Beacon Health, a regulated SaaS whose codebase has accumulated secrets the usual way. First you'll work through the sequencing decisions, then you'll write the full remediation plan an engineering team can execute.

Running the first secret-scan across the whole repo

The situation

Beacon's repo audit finds: a database password and an AWS access key in config.py; a Stripe secret key in a .env file that is committed to the repo; an internal API token in the CI pipeline config; and — discovered later — an old database password still present in git history from two years ago. The app currently reads all of these from config files at startup.

Scenario 1: What comes first?

Quick check

The team is eager to move secrets into AWS Secrets Manager and update the code. What must happen BEFORE (or alongside) the migration, and why?

Nothing — just move the secrets and update the code references

Treat every exposed secret as compromised and rotate it (the keys have been sitting in a repo, possibly in history and on many laptops); rotation and migration go together, because moving a still-valid leaked secret into a vault leaves the leaked copy working

Make the repository private first; then the secrets are safe and no rotation is needed

Delete the config files; that removes the secrets from existence

Scenario 2: The secret in git history

Quick check

The old database password exists only in git history now, not in the current code. How should you handle it?

Ignore it — it is not in the current code, so it is not a risk

Rotate that credential too (anyone with repo access, or anyone who cloned it, can read history), and recognize that git history is exactly where secret scanners and attackers look; purging history is secondary to rotating, because you can never be sure every copy is gone

Rewrite git history to remove it, and consider the problem fully solved

It only matters if the repository is public

Scenario 3: How does the app authenticate to the vault?

Quick check

After migration, the app will fetch secrets from AWS Secrets Manager at runtime. An engineer plans to store a 'master' Secrets Manager API token in an environment variable so the app can authenticate. What's wrong, and what's the fix?

Nothing wrong — one master token is much better than many hardcoded secrets

That just recreates the hardcoded-secret problem at the bootstrap layer; instead the app should authenticate using a platform identity it doesn’t store — an IAM role attached to the instance/container/function — so AWS vouches for the workload and no long-lived secret is needed to reach the secrets manager

Store the master token in a second secrets manager

Hardcode the master token but encrypt the string in the code

Scenario 4: Preventing recurrence

Quick check

The migration is done. How do you keep secrets from creeping back into the codebase?

Send a policy email telling developers not to commit secrets

Add automated secret scanning to pre-commit hooks and CI so commits containing secrets are blocked before merge, enable the platform’s push-protection/secret-scanning, and make secret retrieval from the managed store the standard documented pattern — controls that work even when someone is moving fast

Do a manual code review once a quarter to look for secrets

Trust developers now that they have been trained

Write it up: the migration remediation plan

Now translate the finding into a full remediation plan. Sequence it correctly (rotate + migrate together, fix the bootstrap identity, prevent recurrence) and name the evidence for each step.

Exercise

~30 min

Translate this audit finding into a technical remediation plan

SOC 2 Type II Finding

Hardcoded credentials in source code and CI configuration

ID:

CC6.1-2026-031

Criterion:

CC6.1 — Logical access controls (credential management)

Severity:

Critical

A secret-scan of the application repository found multiple hardcoded credentials: a production database password and an AWS access key in config.py, a Stripe live secret key in a committed .env file, and an internal API token in the CI pipeline configuration. Git history additionally contains a database password committed approximately two years ago. The application reads these credentials from config files at startup. There is no secrets manager in use and no secret scanning in CI.

Auditor Notes

Credentials grant access to production data stores and a payment provider. The repository is private but has been cloned by multiple developers and a CI system. Management cannot rule out exposure. No evidence of misuse was identified, but access logging on the affected systems is limited.

Write your remediation plan in YAML below. Fill in every field — replace all placeholder comments.

Loading editor…

How to use this in practice

A secrets-remediation project always runs in the same order: rotate first (the leaked value is the live risk, and it's worthless once rotated), migrate the new secrets into a managed store while fixing the bootstrap identity so the app authenticates with a platform identity rather than another stored secret, and prevent recurrence with automated scanning and push protection that catch mistakes at commit time. Sequencing is the skill: migrating before rotating leaves live secrets exposed, and storing a master token to reach the vault just relocates the problem. Name the evidence for each step — rotation records, the secrets inventory and access logs, the code diff, a blocked-commit sample — and you've turned the phase's most common finding into a closed, auditable control.

This is the last lesson of the Data Protection phase. You can now trace any data-protection requirement — at rest, in transit, in storage, in backups, in credentials, in motion out the door — to a specific cloud control and the evidence that proves it operates. That translation, from "protect the data" to "here is the setting, the policy, and the report," is the core of the GRC Engineer's craft.