[CSM-1857] Stabilize Azure detector hash_v2 with deterministic iteration

[dipto-truffle]

Summary

• Root cause: ProcessData in the Azure Entra v2 detector iterated Go maps (clientSecrets, clientIds, tenantIds) non-deterministically, causing the same credential to produce different (clientId, tenantId) pairings across scanner runs. This yielded different RawV2 values, different hash_v2 hashes, and duplicate secret rows in the database (the secondary issue in CSM-1857).
• Fix: Iterate map keys in sorted order via slices.Sorted(maps.Keys(...)) and clone caller maps with maps.Clone before verification-driven mutations. Same inputs now always produce the same RawV2/hash_v2.
• Tests: Added unit tests for RawV2 stability (ID count sensitivity, determinism over 50 runs, caller map immutability, hash divergence chain).

Corresponds to trufflesecurity/thog#5936.

Test plan

• go test ./pkg/detectors/azure_entra/serviceprincipal/v2/ -v — all 8 tests pass
• TestProcessData_DeterministicRawV2 confirms identical RawV2 across 50 repeated calls with the same inputs
• TestProcessData_DoesNotMutateCallerMaps confirms caller maps are not modified
• TestProcessData_RawV2DependsOnIDCount confirms RawV2 is populated only with unambiguous IDs
• TestProcessData_SameSecretDifferentRawV2 documents the RawV2 divergence when chunk context differs
• go test ./pkg/detectors/azure_entra/... — all pass

Made with Cursor

---

Note

Medium Risk
Changes the credential pairing/selection logic used to compute RawV2, which can affect deduplication and reported results for Azure secrets (and is reused by v1). Scope is limited and covered by new determinism and immutability tests.

Overview
Stabilizes Azure Entra service principal hash_v2 generation. ProcessData now iterates clientSecrets, clientIds, and tenantIds in sorted-key order and clones the caller-provided ID maps before performing verification-driven delete operations, eliminating cross-run nondeterminism and input mutation.

Adds a new spv2_determinism_test.go suite to assert deterministic RawV2 across repeated runs, document when RawV2 is omitted due to ambiguous IDs, and ensure ProcessData does not mutate the caller’s maps during verification.

^{Reviewed by Cursor Bugbot for commit 0a1c6a7. Bugbot is set up for automated code reviews on this repo. Configure here.}

[CLAassistant]

All committers have signed the CLA.

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, have a team admin enable autofix in the Cursor dashboard.}

[shahzadhaider1]

I might be mistaken, but removing the comments feels a bit aggressive; the PR strips out almost all comments in ProcessData. What do you think?

[dipto-truffle]

[Agent-generated] Good call — restored the comments that explain non-obvious intent:

• "Skip known-invalid client/tenant combinations." (corrected from the misleading original "Skip known invalid tenants")
• "Tenant doesn't exist." / "Tenant exists, ensure this isn't attempted as a clientId." (cross-map deletion rationale)
• "Tenant doesn't exist; shouldn't happen given the check above." (defensive-check note)
• "Tenant is valid but the client ID doesn't exist in it."
• "The result is verified or there's only one associated client and tenant." (break condition)
• "Only include the clientId and tenantId if we're confident which one it is." (ambiguous-ID clearing)

Dropped only // Handle errors. since it was immediately above if verificationErr != nil and added no value.