Add validation logic to catch unexpected commit ranges for pipeline secret detection

Problem to solve

Currently our secrets analyzer calculates the commit range to scan (SHA1 ... SHA2) before sending it to the downstream scanner (Gitleaks). Sometimes this range is provided via external input, which can result in an unexpected or incorrect range (0-commit scans, invalid range, etc.). With our current behavior, we are passing this range to the downstream scanner as is, which can result in the scanner failing or not scanning the intended commit range.

This results in silent errors and can also lead to the pipeline secret detection job passing, even though nothing has scanned. While that is expected behavior, we want to make sure we're validating the commit range before sending it to the downstream scanner in order to ensure we're only triggering the scan when a valid commit range is provided.

Proposal

Update our secrets analyzer to validate commit ranges prior to sending it to Gitleaks.

Implementation plan

TBD