At 4:52 on a Friday, a developer pushes a quick fix to a public repository. Along with the fix goes a .env file holding the company's cloud access key. Automated scanners watch public commits around the clock, and by Saturday morning the company's cloud account is running dozens of GPU instances mining cryptocurrency on the company's bill.
Source code repositories have become one of the most common places credentials leak. On the CompTIA Security+ SY0-801 exam, secrets scanning appears under objective 4.1 as a mitigating control for repositories, and it is new to this version of the exam. This lesson covers what counts as a secret, how secrets leak, how scanning catches them before and after a push, the right order of response when one escapes, and the repository controls around it: branch protection, required reviews, least-privilege tokens and signed commits. Why hardcoded secrets are a vulnerability in the first place was covered in Section 14.
A secret is any value that grants access on its own
A secret is a credential that authenticates or authorizes by itself, with nothing else required. The common types:
- API keys for SaaS platforms, payment processors and messaging services
- Access tokens, including OAuth tokens, personal access tokens for code hosting platforms and CI/CD tokens
- Cloud access keys, such as an AWS access key ID paired with its secret access key
- Passwords and database connection strings
- Private keys: SSH keys, TLS private keys and code signing keys
- Webhook signing secrets and application encryption keys
Most of these are bearer credentials: whoever presents the value gets the access. There is no MFA prompt and no user to notice something strange. Many were created for automation, so they are long-lived and broadly scoped, and nobody is watching when they are used at 3 a.m.
Many secrets also have recognizable formats, which is what makes scanning practical. AWS access key IDs begin with AKIA, GitHub personal access tokens begin with ghp_ or github_pat_, and private keys start with a line such as -----BEGIN OPENSSH PRIVATE KEY-----. Several providers added distinctive prefixes to their tokens specifically so scanners could find them reliably.
Secrets leak through commits, history, forks and build logs
The obvious leak is a key typed into source code. The more common ones are less deliberate:
- A
.envor config file is committed because.gitignoredidn't exclude it, andgit add .swept it in. - A secret is deleted in a later commit, but Git keeps every earlier commit, so it is still in the history.
- A private repository is made public, exposing its entire history at once.
- Forks and clones keep their own copies, and nothing you do to your repository changes them.
- A build step prints environment variables or runs with debug logging, and the secret lands in CI logs that many people can read.
- A secret is copied into a container image layer, a ticket, a chat thread or a pasted snippet.
History is the part people forget. Deleting a file or a line removes it from the latest version only:
$ git log -p -S "AKIA" --all
commit 4e1b7c29d0a3f5e8b6c1d2a7f9e0b3c4d5a6f7e8
Author: J. Rivera <jrivera@example.com>
Date: Fri Oct 16 16:58:41 2026 -0500
Remove credentials file
diff --git a/.env b/.env
deleted file mode 100644
index 3b18e51..0000000
--- a/.env
+++ /dev/null
@@ -1,2 +0,0 @@
-AWS_ACCESS_KEY_ID=AKIAIOSFODNN7EXAMPLE
-AWS_SECRET_ACCESS_KEY=<40-character secret>
Anyone who clones the repository can run that command and read the key out of the commit that removed it.
Public exposure is fast. Attackers continuously harvest new commits on public hosting platforms, and exposed cloud keys are often tried within minutes. Private repositories aren't safe storage either: everyone with read access, every integration with repository permissions, and any attacker who takes over a developer's account can read every secret in the history.