laurentsimon

:/ If we find that we're not analyzing enough commits, can we re-query? That starts to become a bit complicated, though

sounds like a good idea. One worry is around false negative. We want to be sure we don't miss certain patterns. Have you checked, say, 100 SECURITY.md files to validate...

Thank you for this preliminary analysis. If there was a way to map a score to the piece of information that's missing, it would be even better, but I'm not...

> Great, But we need tests! so much to discuss before I add the test. I'll add them at the end.

cc @evverx

Thanks for the feedback @evverx I totally agree we need tweak the score; and also that tools that run on commits/schedules should be rewarded. Maybe give 70% of the points...

> systemd runs LGTM and superlinter on every PR, CodeQL daily and Coverity Scan daily and with this PR applied its score went from 10 to 6. I'm not sure...

update: I've not tweaked the logic for score computation as follows: - linter are run on all PRs. Linters are cheap so this seems acceptable. 1 points is awarded if...

> > supply-chain tool are used. We don't check if it's run on all PRs. So long as it's defined in a workflow and/or run on at least one commit,...

thoughts on rate limiting https://docs.github.com/en/rest/overview/resources-in-the-rest-api#requests-from-github-actions ``` When using GITHUB_TOKEN, the rate limit is 1,000 requests per hour per repository. For requests to resources that belong to an enterprise account on...