Possible additional categories of secrets for rule codeguard-1-hardcoded-credentials

[billbrietstout]

Description

1. Proprietary API keys, internal service tokens, or database credentials that use arbitrary formats
2. Common dev/test passwords like password123, admin, letmein, P@ssw0rd, or application-specific defaults.
3. Assigned to variables without "password/secret/key/token/auth" (e.g., cfg, conn, apiInit, dbCreds, serviceAccount, value)
4. Obfuscated or Constructed at Runtime
5. Formats Not Explicitly Called Out; OAuth, session, or custom JWT-like tokens that don't start with eyJ.
6. SSH keys or certificates without full contiguous blocks (split or commented)
7. Secrets in Comments, Tests, Docs, or History. Leftover in test fixtures, example code, migration scripts, or commented-out sections.
8. Vendor-Specific or Less Common Services like snmp public strings, tokens from Azure, GCP, etc.

What AI Coding Tool are you Using?

Claude Code

AI Model Used

Any

The feedback pertains to which aspect of the project?

Rule definition

[thomas-bartlett]

@billbrietstout, thanks for outlining these cases. Would this scope sound right?

• Identify a coherent set of gaps in the current secret-handling guidance.
• Update the relevant rules, examples, or documentation.
• Keep the guidance model- and tool-agnostic. Where detection is needed, point users to purpose-built secret-scanning tools rather than expanding CodeGuard into a scanner.
• Explain the selected gaps, provide representative secure guidance and examples, keep generated artifacts consistent, and pass repository validation.

This would exclude building a comprehensive secret scanner or maintaining an exhaustive catalog of provider-specific patterns.

Were any of the listed gaps based on specific CodeGuard results or examples that we should use as acceptance cases? If you would like to take this on, I can assign the issue to you.

[billbrietstout]

Yes the scope sums it up. I was too specific, I looked at existing roles and saw a few secrets categories were not included.

Let me know where I can add value.

[thomas-bartlett]

Thanks again for raising these gaps and offering to help. PR #102 documents the proposed boundary: CodeGuard focuses on secure guidance, while dedicated scanners handle comprehensive detection. A few concrete CodeGuard examples would help turn this into focused rule or documentation work.