@uandrei thanks for opening this. Looks like the fingerprint path should be checked in this block too

edit: ehm, actually that's a different issue. I reread the issue and understand now. Definitely need to look into this

@zricethezav if you're happy, I would like to contribute to the repository with a PR to try and fix this issue. I've been looking for a solution and I think I've found a fix that works well when scans are run both locally and on build servers with and without the source parameter set. Please let me know if you're happy for me to raise a PR.

@zricethezav I'll try to explain where I think the issue is and how that can be fixed. To me it seems that the root issue is down to how the path/filepath package reports files, based on the source parameter. When the source parameter is not set (or set to "."), the Walk function will report all the files having relative paths to the current working directory.

This means that when the globalFingerprint is computed in the addFinding function, the finding.File will be different based on the source parameter.

My proposal is to update the DetectFiles function where the fragment structure is created to always use a relative path to reference the file that is being tested.

Replace this:

With this, as I've done in my fork:

relativePath, err := filepath.Rel(d.basePath, p.Path)
if err != nil {
	log.Fatal().Err(err)
}

fragment := Fragment{
	Raw:      string(buf[:n]),
	FilePath: relativePath,
}

The benefits of this change:

• finding Fingerprint generated is the same whether the source parameter is set or not
• .gitleaksignore works OK when source parameter is set
• finding FileName is relative to the working directory or source parameter which fixes the Gitleaks AzureDevOps incorrect linking the findings to files in the git repo