Skip to content

Retrieve SARIF errors and warnings correctly #4837

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

Draft
wants to merge 31 commits into
base: main
Choose a base branch
from

Conversation

bdovaz
Copy link
Collaborator

@bdovaz bdovaz commented Feb 23, 2025

With @nvuillam's request I have:

  • Return the number of warnings (which it didn't do)
  • Correct the calculation of counting the errors or warnings according to: https://github.com/microsoft/sarif-tutorials/blob/main/docs/2-Basics.md#results
    • If the property “level” exists in the object “result” (some linters like gitleaks does not fill it) it counts the number of objects in the array “locations”.
    • If the property “level” does not exist, it only counts the results for the level “warning”, because by default in the specification it is set like this: https://json.schemastore.org/sarif-2.1.0.json
  • Add sarif to cli_lint_errors_count in json scheme (was implemented in code but not added to schema)
  • Add sarif to cli_lint_warnings_count in json scheme
  • Share in two functions (regex and sarif) this logic

There are linters that do not fill out the SARIF level field:

llaville/sarif-php-converters#1 (Fixed!)

pmd/pmd#5573 (Fixed!!)

anchore/grype#2511 (Fixed!!)

In these cases if they do not fill in the “level” field as I have put in the first message, according to the specification the default value is “warning” so it will be reported as such.

There are other cases Python Bandit that fills levels that we do not show in the reporters like “note” level, in this case I make it to be interpreted as warning that is the closest one.

That is, before this PR everything was interpreted as error, now:

  • If they do not fill in the property “level” it will be reported as warning as described in the specification.
  • If they fill it as “error” it will be reported as error.
  • If they fill it as “warning” it will be reported as warning.
  • If they fill it as “note” it will be reported as a warning because it is the closest one we have in the reporters.

Copy link
Contributor

github-actions bot commented Feb 23, 2025

🦙 MegaLinter status: ⚠️ WARNING

Descriptor Linter Files Fixed Errors Warnings Elapsed time
✅ API spectral 1 0 0 1.65s
⚠️ BASH bash-exec 6 1 0 0.02s
✅ BASH shellcheck 6 0 0 0.22s
✅ BASH shfmt 6 0 0 0 0.77s
✅ COPYPASTE jscpd yes no no 2.9s
✅ DOCKERFILE hadolint 131 0 0 33.02s
✅ JSON jsonlint 20 0 0 0.19s
✅ JSON v8r 22 0 0 15.18s
⚠️ MARKDOWN markdownlint 269 0 304 0 23.37s
✅ MARKDOWN markdown-table-formatter 269 0 0 0 140.79s
⚠️ PYTHON bandit 222 67 0 6.35s
✅ PYTHON black 222 0 0 0 5.25s
✅ PYTHON flake8 222 0 0 2.19s
✅ PYTHON isort 222 0 0 0 1.14s
✅ PYTHON mypy 222 0 0 10.5s
✅ PYTHON pylint 222 0 0 36.04s
✅ PYTHON ruff 222 0 0 0 0.65s
✅ REPOSITORY checkov yes no no 42.17s
✅ REPOSITORY git_diff yes no no 1.25s
⚠️ REPOSITORY grype yes 27 no 31.21s
✅ REPOSITORY secretlint yes no no 9.01s
✅ REPOSITORY syft yes no no 2.66s
✅ REPOSITORY trivy yes no no 11.95s
✅ REPOSITORY trivy-sbom yes no no 22.01s
✅ REPOSITORY trufflehog yes no no 4.27s
✅ SPELL cspell 730 0 0 14.91s
⚠️ SPELL lychee 351 33 0 7.55s
✅ XML xmllint 3 0 0 0 1.29s
✅ YAML prettier 160 0 0 0 3.86s
✅ YAML v8r 103 0 0 33.44s
✅ YAML yamllint 161 0 0 4.14s

See detailed report in MegaLinter reports

MegaLinter is graciously provided by OX Security

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants