Veles codecatalyst

[alessandro-Doyensec]

This PR adds the logic to detect Amazon CodeCatalyst personal access tokens by introducing a Git Basic Auth detector.

It also introduce common logic for future git basic auth scanners for other git providers.

[alessandro-Doyensec]

Note:

In c1abfc7 I removed the strings.HasSuffix(path, ".history.txt") condition inside of the FileRequired function, which would have lead to redundant results due to .txt files already being required by the global secrets.Detector.

[erikvarga]

Can we use the simplevalidate library for this? I know we have a separate helper function here for setting up the HTTP request but maybe that can be turned into a simplevalidate.Validator that takes params from the codecatalyst package (e.g. which prefix to check for)

[alessandro-Doyensec]

that takes params from the codecatalyst package (e.g. which prefix to check for)

Yes, I could inject that logic into the EndpointFunc and return an error if the URL is not on the specific domain.

[alessandro-Doyensec]

In fe9c461 I've modified the logic to use the simplevalidate.Validator. I could also have created a gitvalidator in the gitbasicauth pkg but I think this is a nice in-between for now, since I’m not sure yet whether other providers share all the validation logic.

[alessandro-Doyensec]

Hello @erikvarga , thanks for the review.

I noticed that the Linter plugger action has failed due to a false positive (ref: https://github.com/google/osv-scalibr/actions/runs/19894641620/job/57438637665?pr=1577).

That is due to a linter bug (fixed in #1541) where plugin registrations were only picked up if the package name differed from the function’s package. When two packages had the same name but different paths, the registrations weren’t detected.

[erikvarga]

Hello @erikvarga , thanks for the review.

I noticed that the Linter plugger action has failed due to a false positive (ref: https://github.com/google/osv-scalibr/actions/runs/19894641620/job/57438637665?pr=1577).

That is due to a linter bug (fixed in #1541) where plugin registrations were only picked up if the package name differed from the function’s package. When two packages had the same name but different paths, the registrations weren’t detected.

I see, thanks for fixing it. In that case we can just merge this PR after the plugger fixes have been merged.