-
-
Notifications
You must be signed in to change notification settings - Fork 244
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
SARIF report upload fails because of deleted file #1702
Comments
Also, the |
Some linters produce invalid SARIF, so I already added some refactoring of SARIF generated file so Github accepts it, it seems I forgot one ! It's done here ->
I just add to add also such checks for |
I'll be happy to help! However, it will be a while before I get there. I would support putting this in the backest of backlogs, the coldest of iceboxes.. Also, I'm not surprised in the slightest that you've a brilliant response. |
Haha you flatterer ^^ |
@wesley-dean-flexion please can you try again with oxsecurity/megalinter:beta ? ( in about 30 mn when beta release job will be completed) -> https://github.com/oxsecurity/megalinter/actions/runs/2792887110 |
Describe the bug
TL;DR:
Megalinter's SARIF reporter was failing due to matching a file that no longer existed.
Longer version
The SARIF reporter was failing saying:
Exploring the SARIF file from the build artifact revealed:
As reported,
endColumn
was less than 1. (tangentially, it was also less than startColumn)Digging deeper, the thing it found was in a file committed some time ago and subsequently removed. This made finding the issue more fun because the file structure had been changed such that the
physicalLocation.artifactLocation.url
no longer pointed to anything.I was able to work around the issue by adding the following to .megalinter.yml configuration file:
That is, only scan the files and directories that are present in the local repository and not scan the git history..
This is less good. However, once a given commit is scanned and found to be ok, the only time that would change is it the heuristics / patterns in the tool were updated. So, while it's less good, the degree is mitigated to some degree. Let's hope our developers don't get more creative in embedding secrets into their code.
To Reproduce
Steps to reproduce the behavior:
git mv
), push, and merge that commitSARIF_REPORTER
Expected behavior
If a file is not present in the local repository, so not include a reference to that file in a SARIF report.
Screenshots
https://github.com/IMLS/estimating-wifi/actions/runs/2791588499
Additional context
A workaround is to inhibit gitleaks from looking through the repository's history and only focus on the files present.
Alternatively, it may be diagnostically interesting to note that in this instance,
endColumn
was 0; perhaps one can filter out entries where.runs[].results[].locations[].physicalLocation.region.endColumn == 0
either when writing the report or usingjq
as a postprocessor..?I've worked around this so our builds are now...building, so there's no immediate action requested.
The text was updated successfully, but these errors were encountered: