-
Notifications
You must be signed in to change notification settings - Fork 1.7k
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
Monitor JNA's security posture with the Scorecard Action #1583
Comments
Don't take this wrong, but this sound like: "Hey! Great idea here, you get monitoring for free and get more work to do." JNA was and is driven by volunteers. If there is a group, that wants to work on security and such, great, lets add this, if not, no thanks. If you want to improve security: Provide fixes, public resources that can be used by the project (prefereably not tied to a single person), recipes how to built native library. |
Adding a monitoring tool is great if you plan to be the one to take action on it! This looks like a cool tool and I might use it on my downstream JNA-based project, where I'm the one who takes such actions. I had previously looked into the OSSF scorecard and my day-job repo is using the score as one of many code quality tools. Here, it will just generate issues. A good idea if you're interested in being "the one" to monitor these is to fork JNA to your own repo, and set up this action there. Monitor it for a while and take action on the fixes here. I've done that before using various static analysis tools... great way to improve the codebase without adding work to the maintainers. |
For the record, you can see the current "score" at this URL: I scanned the list of things lowering the score and found the usual list of automated things that don't understand this repo:
I'm sure there's probably something actionable somewhere on that list, but the score isn't really representative of the project. |
Hey Daniel, thanks for the quick feedback! Just a few comments:
Unfortunately, there are quite a few things that can't really be handled by an external contributor running Scorecard on a fork. These are things that require changing repo settings, which can only be done by the project's maintainers (changing default workflow tokens to read-only, branch-protection, etc). Indeed, I've only suggested the Scorecard Action now because I've mostly run out of things I can meaningfully contribute to the project via PR (my colleague Joyce also suggested the adoption of a security policy in #1512, but it didn't get traction from many maintainers). Also, the Action can help notify maintainers if something causes their score to decrease. For example, my colleague Joyce improved the project's security by ensuring And if there are notifications that aren't relevant to the project (as you've mentioned is the case for some checks), the maintainer can simply dismiss them and they won't be notified about them any more.
Indeed. I just didn't share this link before because the script that calculates these scores skips a few checks, which can only be run manually or with the scorecard-action: CI-Tests (9/10), Contributors (10/10), and Dependency-Update-Tool (10/10). With these checks, your score goes up to a 5.6/10.
Yeah, that's a bummer that can't really be fixed on Scorecard's end since it uses GH's API, which doesn't detect the licenses.
That's reasonable. You could, however, forbid force-pushes and deletions, which would give users confidence that the ground hasn't shifted beneath them. This would give you a 3/10 without changing your usual workflow. And while it won't improve your score without requiring PRs, you may consider requiring that certain workflows pass before a PR can be merged. This would help ensure your master branch is stable.
Understood. My understanding is that these binaries are generated and stored for release. The suggested model would be to only generate these binaries during the release process and then discard them. If this would take too long, it could be streamlined with an automated release workflow, for example.
Fair!
Out of curiosity, which tools have you used in the past? |
Don't recall the full list as I mostly did one-offs. Generally the same ones I've used on my own project. Not all are still up and running. Some have been incorporated into GitHub's own scanning. I've reduced mine mostly down to just Sonar checks now. Many others were variants on the usual PMD-based checks. Codacy, LGTM, Coverity, CodeQL, Scrutinizer.... anything that I could earn a badge implementing, basically. |
Hey, it's Pedro (see #1567) and I'm back with another security suggestion.
I detected that issue (and my colleague Joyce detected #1508) by using Scorecard, a tool that scans projects for potential improvements to their security posture.
It is also available as the Scorecard Action, which continuously monitors the repository and adds security suggestions directly to the project's Security Panel. In doing so, it can let you know if something accidentally lowers the project's security posture.
I'll send a PR along with this issue adding the Action for you to take a look.
The text was updated successfully, but these errors were encountered: