Security
Secrets management: code and config reading
Crux Read real config and code snippets — a committed .env, a Vault dynamic-secret fetch, a KMS envelope-encryption helper, and a leaky log line — predict the failure and pick the highest-leverage fix.
Your altitude — climbing toward senior
ZeroJuniorMiddleSenior
You are at senior altitude — in orbitSecrets failures are diagnosed in diffs, config, and logs. Read each snippet, predict what leaks or breaks, then choose the fix a senior engineer would make first — before reaching for a tuning flag.
Goal
Practise the loop you run in every secrets incident: read the artifact, find where the value escapes its trust boundary or where the lifetime is wrong, and reach for the highest-leverage fix.
Snippet 1 — the committed .env
# config/.env — tracked in git, pushed to a public mirror last Tuesday
DATABASE_URL=postgres://app:Sup3rSecret@db.prod.internal:5432/main
STRIPE_SECRET_KEY=sk_live_51HxQ...redacted...9aZ
JWT_SIGNING_KEY=hs256-7f3e9c1b2a8d4e6f Quiz
Completed
This .env was committed and pushed to a public mirror. You add it to .gitignore and delete it. Which statement is correct?
Heads-up .gitignore only stops Git from tracking future changes to an untracked file; it does nothing to a file already committed. The three secrets remain in history and on the mirror — they must be rotated.
Heads-up An internal hostname is no protection — the credential is valid, and an attacker who reaches the network (or another leaked entry point) uses it. Every committed secret is rotated, not triaged by perceived sensitivity.
Heads-up History is append-only; a delete commit adds a removal but the prior commits (and the public mirror) still contain the values. You would need to rewrite history, and even then rotation is what ends the exposure.
Snippet 2 — the Vault dynamic-secret fetch
// Fetch a short-lived DB credential from Vault's database engine.
secret, err := client.Logical().Read("database/creds/reporting-ro")
if err != nil {
return err
}
user := secret.Data["username"].(string)
pass := secret.Data["password"].(string)
// leaseDuration is seconds until Vault auto-revokes this credential
lease := time.Duration(secret.LeaseDuration) * time.Second
db := openDB(user, pass)
defer db.Close()
// ... long-running worker keeps using db for hours ... Quiz
Completed
The role mints a credential with a one-hour lease, but this worker runs for hours. What is the defect and the fix?
Heads-up Caching a dynamic credential forever defeats its purpose: the whole point is the short TTL bounds the blast radius. The credential is meant to be renewed or re-fetched, not pinned for the process lifetime.
Heads-up Scope is set by need, not duration — a reporting worker should stay read-only (least privilege). The actual defect is lifetime management: the lease is never renewed, so it expires under the worker.
Heads-up Vault revokes on the lease TTL regardless of open connections; an in-flight connection may survive but new auth fails. You must renew the lease or re-fetch — open sockets do not extend a lease.
Snippet 3 — the KMS envelope-encryption helper
def encrypt_blob(kms, key_id: str, plaintext: bytes) -> dict:
# ask KMS for a data key: plaintext to use now + wrapped to store
resp = kms.generate_data_key(KeyId=key_id, KeySpec="AES_256")
data_key = resp["Plaintext"]
wrapped_key = resp["CiphertextBlob"]
ciphertext = aes_gcm_encrypt(data_key, plaintext) # encrypt LOCALLY
return {
"ciphertext": ciphertext,
"data_key": data_key, # stored next to the ciphertext
"wrapped_key": wrapped_key,
} Quiz
Completed
This helper does local AES-GCM encryption with a KMS-issued data key — envelope encryption. What undoes the whole scheme?
Heads-up Local bulk encryption with a KMS-issued data key is the entire point of envelope encryption — it scales and keeps plaintext off the wire. The defect is persisting the plaintext data key, not encrypting locally.
Heads-up Reusing one data key across everything widens the blast radius of a single key compromise; per-context data keys are preferred. Regardless, the fatal bug here is storing the plaintext data key, not how often you mint one.
Heads-up wrapped_key is the data key encrypted under a KMS key that never leaves KMS — it is safe to store and is exactly what you keep. The leak is the plaintext data_key sitting beside the ciphertext.
Snippet 4 — the leaky log line
app.post("/charge", async (req, res) => {
const cfg = { apiKey: process.env.STRIPE_SECRET_KEY, amount: req.body.amount };
try {
const charge = await stripe.charges.create(cfg);
res.json({ id: charge.id });
} catch (err) {
// dump everything we have to help debugging
console.error("charge failed", { cfg, err, body: req.body });
res.status(500).json({ error: "charge failed" });
}
}); Quiz
Completed
A scanner flags this handler. Where does the secret escape its trust boundary, and what is the fix?
Heads-up Reading from the environment is fine and standard; hardcoding would be worse (back into git). The leak is logging the object that holds the key — fix the log, not the read.
Heads-up Logs flow to aggregators, get exported, and are read by many people and tools; a secret in logs is a well-known leak path. Treat any secret that reaches a log as compromised.
Heads-up Log level does not contain a secret — debug logs are still written, shipped, and read, and config often enables them in prod during incidents. Remove the secret from the log entirely.
Recap
Every secrets incident is read in artifacts: a committed .env means all three values are leaked and must be rotated, not gitignored; a dynamic credential whose lease is never renewed expires mid-run, so renew or re-fetch; envelope encryption is undone the instant you persist the plaintext data key beside the ciphertext — store only the wrapped key and unwrap via KMS; and a secret-bearing object in a log line ships your live key to every aggregator, so redact it and rotate. Read the artifact, find where the value escapes its boundary or its lifetime is wrong, then fix the boundary before you touch a flag.