Teach secrets handling with three things: a plain rule set (no credentials in code, chat or tickets), a hands on exercise using your own tooling for storing and rotating them, and a drill for what to do the minute a credential leaks. Habits form through practice, not warnings.
Why habits beat rules
Everyone knows credentials should not be pasted into code. People still do it when a deadline is close and the proper path is slow. The rule fails because the safe way is harder than the unsafe way.
OWASP lists Insufficient Credential Hygiene as CICD-SEC-6 in its Top 10 CI/CD Security Risks, which shows how familiar and persistent the problem is in delivery pipelines.
The rule set
Keep it short enough to remember.
- Credentials live in the approved secrets store, never in code, config files in a repository, tickets or chat.
- Each credential has an owner and an expiry or rotation plan.
- Use the narrowest scope that works.
- Never reuse a credential across environments.
- If you suspect exposure, report immediately. No blame for reporting.
Rule five matters most. People hide mistakes when punished, and a hidden leaked credential is the worst case.
Make the safe path the easy path
Training will not hold if the approved method is painful. Before teaching, check that a developer can get a new credential into the right place in minutes. If not, fix the process first.
A hands on exercise
| Step | Task |
|---|---|
| 1 | Create a test credential in the approved store |
| 2 | Retrieve it from a sample app without writing it into code |
| 3 | Rotate it and confirm the app still works |
| 4 | Revoke it and observe the failure |
Run it in a sandbox with throwaway credentials. Fifteen to twenty minutes is enough.
The leak drill
Walk through this sequence on paper once a quarter:
- Revoke or rotate the credential first, before cleanup.
- Work out what it could access and check for use during the exposure window.
- Remove it from the place it leaked. Remember that removing it from the latest commit does not remove it from history.
- Record what happened and what change would prevent a repeat.
- Tell the people who need to know.
The key lesson: treat any exposed credential as compromised, whatever the audience seemed to be.
Common traps to teach
- Credentials in sample code that gets copied.
- Credentials echoed in build logs.
- Long lived keys created for a one off task and forgotten.
- Shared accounts with no clear owner.
Where Safeguard fits
Safeguard offers policies and gates, compliance evidence automation and agent identity. It does not offer secret scanning, and it does not offer training courses. Use your existing secrets tooling for detection. A free dependency and code scan is at gold.safeguard.sh/scan.
Quick check
Is deleting a leaked secret from the repository enough?
No. It stays in history and may already be copied. Revoke or rotate it first.
How often should credentials be rotated?
Set a schedule based on sensitivity and what your tooling supports, and rotate immediately on suspected exposure.
Sources
- OWASP Top 10 CI/CD Security Risks: owasp.org/www-project-top-10-ci-cd-security-risks
Last reviewed: 19 October 2026.
