Secret Scanning match logic does not work between (GHES) to (GHEC)

[kyle-jones]

Description

It seems that sometimes the way secrets are matched it captures a bit more/less of the text containing the secret as the value, which causes problems when we try to match them up to migrate the metadata.

For example in the source repo (GHES) the secret value is:
AccountName=vehordereastdevstorage;AccountKey=icsuWApIghSQcCQV/w2mLqd4MUV6o17pLjSK2VFXrP/1ACy0yT+vacorCpJQQLuh8nn/1jKRSajmnRStBaZDYw==

However, for the same code file, the secret value in the target repo (GHEC) is ONLY the actual account key:
icsuWApIghSQcCQV/w2mLqd4MUV6o17pLjSK2VFXrP/1ACy0yT+vacorCpJQQLuh8nn/1jKRSajmnRStBaZDYw==

The existing secret alert migration logic expects the secret values to be identical, and in this case it won't find a matching secret and won't migrate the alert metadata.

The automatic matching and closing of secret alerts does not work between (GHES) to (GHEC) so manual remediation is required.

Refer to prior PR’s https://github.com/github/gh-gei/pull/948 Secret Scanning bug fix when secret values are longer in source/target by dylan-smith · Pull Request #948 · github/gh-gei https://github.com/github/gh-gei/pull/848 Update SecretScanningAlertService.cs by kyle-jones · Pull Request #848 · github/gh-gei

Reproduction Steps

Secret alerts generated out of GHES 3.4 - 3.6 and the current GHEC EMU will not match exactly and will not sync the status of the alter upon migration.

[speisen]

Hi @timrogers, bringing this to your attention. Do you have any updates to share?

[timrogers]

@boylejj is the best person to help me, as I'm no longer working on GEI (sadly!) 🤖