[gei] Secret scanning alert matching logic might need to be reversed for locations

[David Linares]

🚨 Please Read Before Posting 🚨

You are currently in a PUBLIC REPOSITORY.

No Internal Information: Do not share links to internal Zendesk tickets, repositories, team names, or any internal
details.

Confidentiality Matters: Remember that this repository is visible to the public. Avoid posting anything that should
remain confidential or private.

Description

For each secret scanning alert in a source repo, the code currently loops through all locations in that source alert, and expect to find a corresponding location in an alert in the target repo.
However, repo/org migration does not migrate everything, and therefore, the number of alerts and number of locations in each alert will always be a subset of what the source contains.
Therefore, the logic might need to be reversed and loop through all target locations instead of source locations, and consider a match if all target locations have a match in the source locations.

Below is a example:

• secret introduced in 5 different places in the code and sent for review
• secret scanning creates an alert with 5 locations
• reviewers asked author to rework the code to have only that value in 1 place instead of 5, amending or doing a commit on top
• when merging with a "squash and merge" strategy, the alert will still mention 5 locations from commits that were seen, even if not reachable any longer
• when migrating the repo, the target alert will only contain 1 location as these non-existing commits do not exist any more and are not migrated (same thing as if we were cloning as a mirror and trying to find the commit sha)

Here is another example scenario:

• a secret is committed to the source code in one file and is also mentioned in an issue.
• the source alert will have 2 locations.
• the user now edits the issue and remove the secret from the issue.
• the source alert will still have 2 locations.
• now doing the repo migration, as it does not migrate edit history of issues, only 1 location will be found in a corresponding target alert for that same secret.
• the current code will consider it is not a match and not migrate the resolution.

Reproduction Steps

Copy pasting an extract of a test case added to a pull request that will be submitted for review/comments.
The following test case should pass:

        // Source should always have the same or more locations than the target
        // assuming secret migration is done straight after the repo/org migration
        var sourceLocations = new[] {
            new GithubSecretScanningAlertLocation() {
                Path = "my-file.txt",
                StartLine = 17,
                EndLine = 18,
                StartColumn = 22,
                EndColumn = 29,
                BlobSha = "abc123"
            },
            new GithubSecretScanningAlertLocation() {
                Path = "another-file.txt",
                StartLine = 99,
                EndLine = 103,
                StartColumn = 22,
                EndColumn = 29,
                BlobSha = "def456"
            }
        };

        // target location having on less location than source
        var targetSecretLocation = new GithubSecretScanningAlertLocation()
        {
            Path = "my-file.txt",
            StartLine = 17,
            EndLine = 18,
            StartColumn = 22,
            EndColumn = 29,
            BlobSha = "abc123"
        };

       // Add a check showing that this is a match and that the alert resolution will be migrated