V2 detector for confluent

[ap00rv]

Description:

closes #4490

Checklist:

• Tests passing (make test-community)?
• Lint passing (make lint this requires golangci-lint)? (linting passes for changes in this PR)

Local testing

V2 detector is catching a real confluent cloud V2 secret

go run main.go
                                                                                        
  <REDACTED FOR BREVITY>                                                   
                                                                                        
🐷🔑🐷  TruffleHog. Unearth your secrets. 🐷🔑🐷

2025-10-08T11:13:22-07:00	info-0	trufflehog	running source	{"source_manager_worker_id": "nVzum", "with_units": true}
✅ Found verified result 🐷🔑
Detector Type: Confluent
Decoder Type: PLAIN
Raw result: 63IISQDQTUB3JNJ7
Rotation_guide: https://docs.confluent.io/cloud/current/security/authenticate/workload-identities/service-accounts/api-keys/best-practices-api-keys.html#rotate-api-keys-regularly
Version: 2
File: /Users/apoorvmunshi/Downloads/api-key-63IISQDQTUB3JNJ7.txt
Line: 4

2025-10-08T11:13:22-07:00	info-0	trufflehog	finished scanning	{"chunks": 1, "bytes": 180, "verified_secrets": 1, "unverified_secrets": 0, "scan_duration": "2.200042ms", "trufflehog_version": "dev", "verification_caching": {"Hits":0,"Misses":1,"HitsWasted":0,"AttemptsSaved":0,"VerificationTimeSpentMS":0}}

[shahzadhaider1]

Good work.
Added a few questions.

[shahzadhaider1]

According to this, we must send the API key in an Authorization: Basic {credentials} header, which requires us to provide the credentials as the API key ID and associated API secret separated by a colon and encoded using Base64 format.

So my question is, how useful is this API secret alone without an API key ID? I get that we can detect and potentially verify the API secret using your new implementation, but can an API secret alone be exploited if leaked?

[ap00rv]

good point ! API secret cannot be exploited without the corresponding API key.

[ap00rv]

added API key detection in V2, similar to V1. Sorry about that.

[shahzadhaider1]

Thanks for the update. I am not saying this is wrong but I do have some concerns regarding the way we are verifying the secrets. Right now, we are detecting keys and secrets, but we are verifying only secrets, instead of verifying a pair of key and secret.

For example, I copied the secret you have added in the test file and pasted in a file, and added a fake api key "0123456789ABCDEF", and ran a scan and the detector is showing this finding as a verified secret. However, this is a fake pair of secret and if this pair of API key and secret is leaked, they are worthless(correct me if I am wrong here).

So maybe we should switch to the API-based verification. I am open to suggestions here but just giving you the idea of how we detect and verify secrets in the detectors.

I am attaching the screenshot of the scan result where the incorrect API key is shown as verified.

[ap00rv]

There is no way to accurately verify confluent secrets via API (for both V1 and V2) . V2 secrets don't need API verification since they have CRC32 checksum appended. But, I have added API key + secret detection for V2 (instead of just secrets detection). More context in the issue : #4490

[shahzadhaider1]

added API key detection in V2, similar to V1. Sorry about that.

Thanks for adding the API Key ID detection, however, I do not see the API Key ID actually being used in the verification part. The reason I asked for the addition of API Key ID here was because in order to verify a confluent API Key, we need both the API key ID and the associated API Secret as mentioned in the docs.

[shahzadhaider1]

Here is another example. I have created the following secret using a Python script:

confluent_key=ABCDEF1234567890
confluent_secret: cfltAsBrY8jb/2fxvr4eyerR8Cel/PnpFSuWfn5Y3Rfzgg70rfKOczuFrmk3LUYA

Both of these are fake, yet they were able to bypass the checksum-based validation, and the detector marked them as a verified result.

[ap00rv]

Hi @shahzadhaider1 , The test secret you shared in the last comment has a valid checksum. That is why it's passing the check. However, I think we can rely on this checksum based mechanism because of the following reasons :

• the new pattern for Confluent Secrets is very specific and it's unlikely that random strings will match this pattern, especially due to the CRC32 checksum being appended at the end.
• If the secret is present in text and valid, then it is very likely that a valid Confluent key pattern (16 bytes of uppercase characters or numbers only) is also present in the nearby text, in which case we can consider it the key+secret pair as valid. for the key pattern, we are using \b which will ensure that the key pattern only matches complete words and not random characters.

I think the above checks are sufficient to eliminate FPs in real world. Please let me know your thoughts. Thanks !

[ap00rv]

@shahzadhaider1 please let me know if you agree my last comment in this thread. Thanks !

[ap00rv]

after some internal discussion, I have decided to convert this to a draft. we are thinking about how we can accurately perform validation on different types of API keys. Thanks a lot for your inputs.

[ap00rv]

@shahzadhaider1 addressed all your comments. Please let me know if you need any more changes. I also tested that a valid confluent cloud API key can be detected by V2 detector.

[shahzadhaider1]

@shahzadhaider1 addressed all your comments. Please let me know if you need any more changes. I also tested that a valid confluent cloud API key can be detected by V2 detector.

Hey @ap00rv, thanks for clarifying that. I completely understand that V2 secrets have a built-in checksum, which makes offline validation possible, that part makes sense. However, I did some testing of your branch and shared a concern here.

Two things I wanted to discuss:

1. The secret pattern hasn't really changed significantly and the regex pattern in the v1 of the Confluent detector can still detect the new API secrets, so do we really need a v2?
2. I get that there is a new prefix added and we can validate the secrets based on checksum but my concern is more around the verification logic. In TruffleHog, a “verified” result means the credential (or credential pair) can be used to access a resource, not just that it’s structurally valid. With the current logic, a secret alone (if it passes the checksum) can be marked as verified, but without its matching API key, it’s not actually usable, so in that sense, it’s not a verified secret, just a validated one. Let me know if you need more clarification.