In general, the fix is to ensure that sensitive data (the API keys returned from create_api_key) are never written directly to logs or standard output in clear text. Non-sensitive metadata such as counts, IDs, and tier names can remain logged.

In this code, the sensitive flow is: APIKeyService.create_api_key() returns a dict that includes "api_key", regenerate_api_keys() stores that in new_api_key and in the "new_api_key" field of each migration record, and print_report() prints that field ("→ New API Key: {new_key}"). results['keys_to_regenerate'] itself is safe to print; the real problem and the reason for the taint is that results also contains the sensitive new_api_key fields. The minimal fix that preserves existing functionality while removing the clear-text exposure is:

• Stop printing the actual API key value in print_report. Instead, print only non-sensitive metadata (e.g., key IDs and tier, which are already there).
• Optionally, keep "new_api_key" available in the results structure so that calling code (if any) can decide how to handle it, but do not print it or log it. Since this script is stand-alone and only uses results for printing and exit codes, leaving the field in place but not printing it is functionally equivalent for the caller.
• No changes are needed in APIKeyService.create_api_key itself; it is reasonable for that service to return the key exactly once to trusted callers.

Concretely, in backend/scripts/regenerate_api_keys.py:

• In print_report, remove or comment out the line that prints new_key (" → New API Key: {new_key}"). We will simply delete that line. This removes the only direct clear-text logging of the actual API key in the script.
• Leave the lines that print counts (results['keys_to_regenerate'], etc.) as they are; they are safe and useful.

No new methods or imports are needed; this is just removing a single print of sensitive data.

In general, the problem should be fixed by ensuring that sensitive values (API keys) are never written to logs or stdout/stderr in clear text. Instead, only non-sensitive metadata (IDs, counts, tiers, truncated hashes, etc.) should be logged. Any structures that carry secrets (like migrations and results) must not be serialized, printed, or logged in a way that might emit those secrets, unless they are explicitly stripped or redacted first.

For this specific code, the best minimal fix is to change how the migration report prints details so that it no longer outputs the full new_api_key. We can still display IDs and counts for operational visibility, but omit or redact the actual API key. This addresses all variants because the sensitive taint originates from result["api_key"] / new_api_key in migrations, which is what makes results tainted; by ensuring that we never print the key itself in print_report, we remove the clear-text exposure. We do not need to change how results is constructed, only how it is rendered.

Concretely, in backend/scripts/regenerate_api_keys.py:

• In print_report, inside the status == "regenerated" branch, remove or replace the line:

  print(f"    → New API Key: {new_key}")

• Option A (most conservative): drop the line entirely so the API key is never printed.

• Option B (if you want to give a hint without exposing the secret): print only a redacted form, e.g., last 4 characters, clearly labeled as redacted.

Given the instructions to avoid logging sensitive data, Option A is the safest, but Option B still avoids logging the full key and is often acceptable in practice. I’ll implement Option B so operators can match a key they just copied, while making sure the full key never appears.

No additional imports or helpers are necessary; we can compute a simple redacted string inline.

In general, sensitive credentials (like API keys) must never be logged or printed in clear text. When some visibility is useful (for operators to match keys), you can log a non-sensitive derivative such as the database ID or a truncated/masked version of the key, or avoid outputting it at all and instead rely on secure side channels.

The best fix here is to stop printing the full new_api_key in the print_report function and, if needed, replace it with a safe, non-sensitive representation. The rest of the script already avoids logging the API key via the logger and identifies keys primarily by key_id, tier, and name, which should be sufficient. To minimize functional change while eliminating the vulnerability and satisfying the analyzer, we will:

• Modify print_report so that it never outputs the full new_api_key.
• Instead, print either:
  • nothing about the raw key, or
  • a masked version (e.g., last 4 characters) clearly marked as partial, which is safe because it does not allow reconstruction of the key.
• Keep all other metrics, including results['failed'], unchanged; we don’t need to alter the structure of results itself.

Concretely, in backend/scripts/regenerate_api_keys.py:

• Inside print_report, in the "regenerated" branch (status == "regenerated"), replace:

new_id = migration["new_key_id"]
new_key = migration["new_api_key"]
print(f"  ✓ Key ID {old_id} ({old_name}, tier: {tier})")
print(f"    → New Key ID: {new_id}")
print(f"    → New API Key: {new_key}")

with something that does not expose the full key, e.g.:

new_id = migration["new_key_id"]
new_key = migration["new_api_key"]
masked_key = f"{new_key[:4]}...{new_key[-4:]}" if new_key and len(new_key) > 8 else "<hidden>"
print(f"  ✓ Key ID {old_id} ({old_name}, tier: {tier})")
print(f"    → New Key ID: {new_id}")
print(f"    → New API Key (partial): {masked_key}")

or, if you prefer, omit the API key line entirely. This change requires no new imports and keeps existing behavior (showing “which key” was created) in a much safer, non-reversible way. Since the taint now only flows into a masked, derived value that does not reveal the secret, CodeQL’s concern about clear-text password/API-key logging at this sink will be addressed.

General approach: do not print the API key value anywhere (logs or stdout). Instead, report non-sensitive identifiers (key IDs, names, tiers) and, if necessary, truncated or masked representations of keys. Since this is a migration script, we can still provide a useful report by omitting or masking new_api_key in the human-readable output. We should also avoid storing the full api_key in large, long-lived result structures when not strictly needed.

Best targeted fix here: keep the internal data structure (results["migrations"]) unchanged for compatibility, but update print_report so that it no longer prints new_api_key. Optionally, we can replace it with a masked indication or a generic “API key generated” message. This addresses all CodeQL variants because the tainted flow into the sink (print) is broken: even though results and migration remain tainted, the actual secret (migration["new_api_key"]) is no longer included in the output.

Concretely, in backend/scripts/regenerate_api_keys.py:

• In print_report, in the "regenerated" branch:
  • Remove or change the line print(f" → New API Key: {new_key}").
  • Potentially rename new_key to new_key_id or similar to keep clarity, but not required.
• The "would_regenerate" (dry-run) branch currently only prints key ID, name, and tier, which are fine; no change needed.
• No changes are needed in APIKeyService or in how results is composed unless you want to also stop storing the full API key in migrations. To keep behavior as close as possible, we will only stop printing it.

No new imports or helper methods are required; we only alter the string formatting in print_report.

In general, to fix clear‑text logging of sensitive data, you should either: (a) avoid logging/printing the sensitive value at all, logging only non‑sensitive metadata; or (b) mask/redact the value so that the secret cannot be reconstructed. For API keys, the usual pattern is to show only part of the key (e.g., last 4 characters) or a hash/fingerprint.

For this script, the minimal and safest fix without changing the overall functionality is to stop printing the full new_api_key in print_report. The script already logs IDs and tier names, so operators can still see which keys were processed. If you still want a per‑key handle for verification, you can print a short fingerprint derived from the key (e.g., a SHA‑256 hash truncated to a few hex characters) instead of the raw key; but that would require adding hashing code. Since the requirement is to avoid clear‑text logging of the API key, and we must minimize changes, the best fix is simply to remove or redact the line that prints new_key.

Concretely, in backend/scripts/regenerate_api_keys.py, within print_report, replace:

231:                 new_key = migration["new_api_key"]
232:                 print(f"  ✓ Key ID {old_id} ({old_name}, tier: {tier})")
233:                 print(f"    → New Key ID: {new_id}")
234:                 print(f"    → New API Key: {new_key}")

with a version that does not output new_key. For instance:

• Drop new_key entirely and print only IDs and tier, or
• Replace the “New API Key” line with a note that the key value is intentionally not printed.

No new imports are required if we simply stop printing the key; we don’t need to touch APIKeyService or any other file. This single change addresses all three CodeQL variants, because the tainted value result["api_key"] is no longer propagated into a clear‑text output sink.

General approach:

• Do not print the raw API key (new_api_key) directly in print_report.
• Avoid passing the raw API key through the same results/migrations structure used for general reporting and potentially logging.
• If we still need to expose new API keys for operators, provide a safer, more explicit mechanism (e.g., a separate “secrets output” structure the caller can decide how to handle) or make printing keys opt‑in via a CLI flag.
• Ensure we do not treat key IDs as secrets; only the actual API key value should be removed from the logging/reporting path.

Best minimal fix while preserving functionality:

1. Stop including new_api_key in the migrations entries used for print_report.

   • In regenerate_api_keys, change the "new_api_key": new_api_key field to something non-sensitive (e.g., None) in the migrations.append(...) call for successful regenerations.
   • Similarly, for the dry‑run and error cases, leave "new_api_key": None as it is (already not exposing data).

2. Stop printing the new API key in print_report.

   • In print_report, under the status == "regenerated" branch, remove or replace the line print(f" → New API Key: {new_key}").
   • We can still print the non-secret metadata (old ID, tier, new key ID). Key IDs are not secrets, so print(f" → New Key ID: {new_id}") is safe and should remain.

3. (Optional but consistent): If we want admins to still obtain the new API keys in a controlled way, we can:

   • Keep new_api_key only in the in-memory results structure returned from regenerate_api_keys, but not in migrations that print_report iterates. Instead, add a separate top‑level list, e.g., "new_keys_secrets": [...], that contains dicts with old_key_id, new_key_id, api_key. Then, the main function (or the caller) can decide what to do with it (write to a secure file, print only when a --show-secrets flag is passed, etc.).
   • However, since we’re constrained to the shown snippets and want minimal change, the simplest and safest fix is just not to surface new_api_key at all via print_report/stdout and to keep the rest as-is.

Given the instructions, I’ll implement the minimal change:

• In backend/scripts/regenerate_api_keys.py:
  • In the migrations.append dict for the status == "regenerated" case, set "new_api_key": None instead of new_api_key.
  • In print_report, remove the retrieval of new_key = migration["new_api_key"] and the subsequent line that prints "→ New API Key: {new_key}".

This removes the clear-text logging path for the API key while keeping the rest of the reporting (including non-secret key IDs) intact.

No changes are needed in backend/app/services/api_key_service.py for this issue.

In general, the fix is to avoid printing the raw API key value anywhere. The script can still report that a new key was created and show its ID and metadata, but not the actual secret. If operators genuinely need to see the key once, that should be handled via a more controlled/explicit output mechanism (e.g., a dedicated flag), but given the current requirements we should remove the clear-text API key from the report.

The minimal, non‑functional‑breaking change is to adjust print_report in backend/scripts/regenerate_api_keys.py so that it no longer prints migration["new_api_key"]. Instead, we can print a generic message that a new key was generated and where to retrieve it, or note that the key is intentionally not shown. This keeps the structure of results and migrations untouched, so all other code paths remain the same. No changes are needed in APIKeyService itself.

Concretely:

• In print_report, in the elif status == "regenerated": block, remove or replace the line:
  • print(f" → New API Key: {new_key}")
• Optionally, replace it with something like:
  • print(" → New API Key: [REDACTED - not logged]")
    or a similar wording so the report is still informative.
• We do not need any new imports or helper methods; this is a simple change to the printed string.

This single change will address all CodeQL variants because they all point to the same sink: the printing of new_key (the API key) as clear text.

In general, the fix is to ensure that sensitive data (the raw API key) is never written to logs or stdout/stderr. Instead, logs should use non-sensitive identifiers (such as key IDs) or redacted/masked representations and keep the API key only in memory for the minimal time necessary to display it securely to an authorized operator, if at all.

For this specific code, we should:

• Stop including new_api_key in the migrations report structure, so it never reaches print_report.
• Adjust print_report so it no longer prints new_api_key.
• Optionally, clearly document in the report that the new key is intentionally omitted from logs, and rely on whatever the caller already does (or could do in a follow-up) to present the key in a safer, ephemeral way if needed.

Concretely, in backend/scripts/regenerate_api_keys.py:

1. In the regeneration loop, immediately after calling create_api_key, we currently do:
   • new_api_key = result["api_key"]
   • Store "new_api_key": new_api_key into each migration entry.
2. We should:
   • Still extract new_api_key so we can use it locally if needed, but not put it into the migrations dict that is returned and printed.
   • Replace the "new_api_key": new_api_key field with something non-sensitive, such as None or a placeholder string, or simply omit the field if the structure is not strictly relied upon elsewhere. To avoid changing external behavior too much, we can keep the key but set the value explicitly to None.
3. In print_report, remove the line print(f" → New API Key: {new_key}"), and optionally replace it with a message like print(" → New API Key: [REDACTED - see secure output]") or, more neutral, print(" → New API Key: (not logged)"). This preserves the shape of the report while avoiding secret leakage.
4. No changes are needed in backend/app/services/api_key_service.py for this particular issue, since the service already avoids logging the API key and only returns it once.

No new imports, methods, or dependencies are required; all changes are confined to backend/scripts/regenerate_api_keys.py within the shown snippets.

In general, the fix is to ensure that sensitive values such as raw API keys never appear in logs or user‑visible output in clear text. For this script, that means (1) removing or masking the direct printing of new_api_key in the migration report, and (2) ensuring that error messages and report structures do not inadvertently include those secrets.

The minimal, functionality‑preserving change is to stop printing the full API key and instead print only a safe, non‑sensitive representation, such as a fixed‑length prefix with the rest masked. We can also keep the API key in results["migrations"] if the calling code (or operator) needs to handle it programmatically, but we must not display it in the report. To additionally satisfy the analyzer, we can explicitly mask the key when constructing the migrations entries that are meant for human consumption, or at least when printing. Concretely:

• In regenerate_api_keys, when constructing the migrations entry for a successful regeneration, replace "new_api_key": new_api_key with "new_api_key": None or a masked/truncated representation that is not usable as a credential.
• In print_report, remove or change the line that prints new_key so it never prints the full API key. If a hint is useful for operators, print a masked form (e.g., first 4 characters and last 4 characters, with the middle replaced by *), computed locally in print_report.

These changes only affect backend/scripts/regenerate_api_keys.py; no changes are needed in backend/app/services/api_key_service.py. No additional imports are required; masking can be done with basic string operations.

General approach: Ensure that raw API keys are never stored in or exposed via structures that are later logged or printed, and keep any sensitive values as ephemeral as possible (e.g., only used to show one-time output to the operator, or written to a dedicated secure channel). Specifically, we should avoid including new_api_key inside the migrations entries that are returned from regenerate_api_keys, because results (containing migrations) is passed to print_report(results) and may be logged or displayed. Instead, we can handle the API key in a separate, clearly-scoped way (e.g., print it directly when created, with a clear warning, and only once) and track only non-sensitive metadata in migrations.

Best minimal fix without changing existing external behavior too much:

1. In backend/scripts/regenerate_api_keys.py, inside regenerate_api_keys:

   • Stop storing new_api_key in each migration dict. Replace the "new_api_key": new_api_key field with something non-sensitive, such as "new_api_key_redacted": True (or simply omit that field altogether). This removes the secret from the aggregate results structure and breaks the taint chain into results.
   • Optionally (and safely) log or print the new API key immediately after creation, but keep that outside of any aggregated structure. The comment already says # Note: API key is not logged for security - see report output instead; to stay conservative and keep functionality, we should not log the key and should keep any existing behavior of print_report (which we are not shown). Given the constraint to only change shown snippets, the safest approach is simply to avoid putting new_api_key into migrations and let print_report work with the remaining fields (key IDs, status, etc.). If print_report expects new_api_key, it will just see None, which is safer than exposing secrets and is an acceptable hardening for an admin-only migration script.
   • This change ensures that results contains no raw key material, so logging results["failed"] or any other counter is guaranteed not to leak the key.

2. No change is required to backend/app/services/api_key_service.py for logging purposes, since that file already avoids logging the api_key and only returns it once in a dict. The main issue arises from how that return value is propagated into a long-lived report.

Concrete edits:

• In backend/scripts/regenerate_api_keys.py, in the migrations.append({ ... }) block for the successful regeneration, change:

  "new_api_key": new_api_key,

  to either:

  "new_api_key": None,

  or (better, to reflect semantics explicitly):

  "new_api_key": None,  # API key intentionally omitted for security

  This ensures that no secret is reachable via results.

No other lines need to change to satisfy the clear-text logging concern, and we do not need to modify the flagged log line itself, since after this fix results no longer contains the sensitive field.