## 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

```text
>> 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.
2. 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.
3. 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.
4. 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