#99 feat(rules): add Azure & GCP service-account key patterns to secret detector (#93)

[Anonymous]

Originally created by: stevenmini2019

Summary

Closes [#93].

Adds detection for cloud service-account credential shapes that the original _CREDENTIAL_PATTERNS missed:

• Azure Storage connection-string AccountKey=... (44-char base64)
• Azure Service Bus / Event Hubs / IoT Hub SharedAccessKey=...
• GCP service-account key JSON marker "type": "service_account"
• GCP SA client email <name>@<project>.iam.gserviceaccount.com

Test plan

• Added AZURE_GCP_CREDENTIALS detection cases (BLOCK on exfiltration) and AZURE_GCP_BENIGN precision guards (no over-block on ordinary emails / benign lookalikes).
• Full secrets-rule suite: 63 passed.

All fake values are synthetic and split via + so GitHub push-protection / gitleaks CI stays clean.

[Anonymous]

Originally posted by: fu351

Thank you for adding these — the Azure and GCP key patterns (AccountKey=, SharedAccessKey=, the service-account JSON marker) are a real, welcome improvement and well-scoped. One change before I merge: the GCP service-account EMAIL pattern (…@….iam.gserviceaccount.com) is currently in the STRONG _CREDENTIAL_PATTERNS tier, which can drive a hard BLOCK on external destinations — but an SA email is an identifier that legitimately appears in configs, logs, and tickets, not credential material, so it risks false-positive BLOCKs. Could you move just that email pattern to the weaker AUTH-only evidence tier (or drop it)? Once that's addressed and CI is green I'll merge. Really appreciate the contribution, and sorry for the slow response!

[Anonymous]

Ticket changed by: fu351

• status: open --> closed

[Anonymous]

Originally posted by: fu351

Thank you for closing [#93] — all four patterns are well-anchored (AccountKey=, service_account marker, .iam.gserviceaccount.com), each paired with a benign-lookalike negative test (63/63 green), fixtures built by string-concat to stay gitleaks-clean, self-corrected a ruff nit same-day. One item still open, partly on me for merging early: I'd flagged the GCP SA email pattern went into the STRONG _CREDENTIAL_PATTERNS tier (hard BLOCK), but an SA email is an identifier (shows up in configs/logs), not credential material — risks false-positive blocks. It merged still in that tier. Could you move it to the AUTH-only tier, or we'll take it as a follow-up? Everything else is exactly what I want more of — thank you.

[Anonymous]

Originally posted by: fu351

The Azure and GCP service-account key patterns you added to secrets.py close a real gap, and the benign-lookalike tests you wrote alongside them show you're thinking about false positives, not just detection. Since you're already fluent in that file, [#197] (engine: add a PyPI API-token pattern to the secret-detection rule, level-4) is the same file and pattern shape, and [#198] (engine: escalate bulk-delete of gitignored, uncommitted directories, level-7) is a good next rung after that. Issues are labelled level-1 through level-10 now — commenting on one claims it.

[Anonymous]

Originally posted by: fu351

@stevenmini2019 The Azure and GCP key patterns are still on duty in the secret detector. Solid, durable work.

Quick community roll-call: are you in the Doberman Discord? If yes, drop your handle here (or DM me there) so I can match the GitHub side of your work to your Discord name. If not, you're warmly invited: https://discord.gg/Sfy5XGNqty