Security Review Comments

Option B is the only response that adequately handles the severity. Key elements:

1. Blocking: prefix — this is not optional.
2. Git history warning — even if removed, the key is visible in history. This is the critical insight most developers miss. Rotating the key is required regardless.
3. Correct fix — environment variable or secrets manager.
4. Merge gate — explicitly states the condition for merge.

Using "nit:" for a hardcoded credential would be a serious mistake — it signals the issue is optional. Security findings must use "Blocking:" or equivalent. For credentials exposed to git history, rotation is non-negotiable even if the PR is never merged.

`'; DROP TABLE users; --` is the classic SQL injection payload — the single quote closes the string, the semicolon ends the statement, DROP TABLE users is the malicious command, and -- comments out the rest of the original query.

Using a concrete attack payload in a security review comment is intentional: it makes the vulnerability tangible and shows you understand the actual risk. Abstract language like "malicious input" doesn't communicate the specific threat as effectively.

The fix — parameterised queries (also called prepared statements) — separates the query structure from the data, making injection impossible. Examples: cursor.execute("SELECT * FROM users WHERE id = ?", [user_id]) in Python, or ORM query builders.