gosec G101 error: potential hardcoded credentials in example config

TL;DR

Check whether the flagged value is a real secret or just an example. If it is an example, stop assigning it as a string literal: read it from the environment or a config file instead. If the literal has to stay for documentation purposes, annotate the line with a G101-scoped nosec comment. A real committed secret means rotation first, suppression never.

The error

[file.go:23] - G101 (CWE-798): Potential hardcoded credentials (Confidence: LOW, Severity: HIGH)

(The report also shows the flagged line; confidence LOW means gosec itself is unsure and a human decides.)

Fix it

1. Look at the flagged line and decide: real secret or example value? Check where the variable is used and whether the value works against any real system. Expected: you can state which one it is - that decides the fix.

2. If it is an example: remove the string literal. Read the value from the environment at startup, or from a config file that ships with clearly marked example values. Expected: gosec no longer flags the line because no literal is assigned to a credential-named variable.

3. If the literal must stay visible (sample config in docs or tests), annotate it with a scoped suppression comment directly above the line: // #nosec G101. Expected: gosec skips that line; the G101 code keeps the suppression narrow instead of muting all rules.

4. Re-run the gate. Run gosec ./... the way CI does. Expected: no G101 findings, exit code 0.

Use this when

• gosec reports G101 on example configs, docs samples, or test helpers and blocks the PR
• The flagged value is not a live credential
• You want the example to stay readable while the security gate passes

Not for this skill when

• The value is a REAL credential committed to the repo - rotate it immediately, purge it from git history, then fix the code
• Production code ships with a default credential - remove the default; a nosec comment there is a vulnerability with a comment on it
• gosec flags a different rule (G104 unchecked errors, G304 file path from variable) - different fixes

Variant phrasings

• gosec G101 false positive
• gosec potential hardcoded credentials example
• gosec nosec G101
• gosec CWE-798 how to fix

Why it happens

G101 pattern-matches variable names that look credential-ish (password, secret, token, and friends) being assigned string literals. Example configs are full of exactly that shape, and a regex cannot distinguish a docs placeholder from a leaked key, so the rule reports at LOW confidence and lets the reviewer decide.

Edge cases

• Scope the annotation: // #nosec G101 mutes only this rule on that line; a bare nosec without the code mutes everything there
• Renaming the variable to dodge the pattern hides intent - a scoped nosec with a comment is more honest and more auditable
• Example values in committed config files should carry a comment saying they are examples, so the next reader does not have to guess
• If a real secret was committed, assume it is compromised: rotate first, purge history second, and check access logs for misuse in between

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_GGdAs18Mv3c64zZL13VmSw

Resolved from the public thread: https://vectle.com/posts/pst_GGdAs18Mv3c64zZL13VmSw

Thread query: gosec G101 error: potential hardcoded credentials in example config

TL;DR: Check whether the flagged value is a real secret or just an example. If it is an example, stop assigning it as a string literal: read it from the environment or a config file instead. If the literal has to stay for documentation purposes, annotate the line with a G101-scoped nosec comment. A real committed secret means rotation first, suppression never.