bandit B105 error: hardcoded password string flagged on test fixture

TL;DR

First confirm the flagged value is really test-only, then stop hardcoding it: read it from an environment variable in the fixture instead of a string literal. If the value is a genuinely inert placeholder the tests never connect with, add a # nosec B105 comment on that line. Never suppress a real credential - rotate it instead.

The error

>> Issue: [B105:hardcoded_password_string] Possible hardcoded password
   Severity: Low   Confidence: Medium
   Location: tests/conftest.py:14

(Bandit also prints the flagged string value on the next line; the rule ID B105 is the part that matters.)

Fix it

1. Confirm the value is test-only. Search the repo for every reference to the fixture and check none of them run in production code.

Expected: matches only under tests/ or clearly marked example config - safe to treat as a fixture.

1. Stop hardcoding it. Change the fixture to read the value from an environment variable, with the test suite setting that variable in the CI job. Keep a placeholder default only in test code.

Expected: re-running bandit no longer reports B105 on that line, because there is no string literal to flag.

1. If the value must stay as a literal (a docs example or an inert placeholder), suppress just this rule on that line with an inline comment: append # nosec B105 to the flagged line.

Expected: bandit skips the finding; the rule code keeps the suppression scoped to B105 instead of silencing every rule.

1. Re-run the gate the way CI does. Run bandit -r tests/ (or your project's bandit target).

Expected: "No issues identified." and exit code 0.

Use this when

• Bandit reports B105 on a test fixture or example config and blocks the PR
• The flagged string is not a real credential
• You need the fixture to keep working while the security gate stays green

Not for this skill when

• The flagged string is a REAL credential - rotate it at the provider, purge it from git history, and treat it as an incident; do not nosec it
• The finding is in production code paths - fix it properly with a secrets manager or environment injection
• Bandit flags a different rule (B101 assert used, B404 subprocess import) - those need their own fixes

Variant phrasings

• bandit hardcoded password string false positive
• bandit B105 test fixture
• bandit nosec B105
• bandit possible hardcoded password

Why it happens

Bandit scans for string literals assigned near credential-ish names, and test fixtures need realistic-looking values, so fixtures trip the rule constantly. The scanner cannot tell a test-only placeholder from a production secret - that judgment is the human's (or the reviewer's) job, and the gate fails closed on purpose.

Edge cases

• Always scope the suppression: # nosec B105 suppresses only this rule, while a bare # nosec silences every rule on the line
• B106 (hardcoded credential in function arguments) and B107 (hardcoded string) are the same family - the same fix applies
• You can skip whole test directories in bandit config, but a targeted fix beats a blanket skip for auditability
• If the value turns out to be real, rotation alone is not enough: it is in git history, so purge it with filter-repo or equivalent and rotate again after purging

Provenance

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