Hey Jordan, The tool is only meant to be informative regarding the project's supply-chain security posture and gives actionable suggestions on how it can be improved. However, it doesn't create issues, bug maintainers and volunteers with notifications/emails, or make any assumptions regarding maintainer/volunteer responsiveness. Maintainers decide when they wish to check the GitHub Security Dashboard to check the project's security posture.
What actionable benefit could this provide the project? > Some of the suggestions it gives for PHP are: - add a security policy to the repo where security vulnerabilities can be reported privately (the file could simply point users to the instructions at https://wiki.php.net/security, for example). - set GitHub workflow dependencies to adopt hash-pinning instead of major-version pinning. This is to eliminate the risk of tag-hijacking attacks where a malicious commit is published to an Action you rely on and the tag is then recreated to point to that malicious commit. Dependabot or Renovatebot (which the tool also recommends adding to the project) can then be used to keep your dependencies up-to-date. - set all GitHub workflows with top-level read-only permissions. It recognizes that almost all PHP's workflows have top-level read-only permissions, but points out that github/workflows/labeler.yml doesn't (though it does have job-level contents read-only permissions). - and yes, enforce Code-Review and maximal Branch-Protection. I understand this would be quite impactful on the project's current workflow, but it's the sort of thing that would mitigate the sort of attack @ricardoboss mentioned in the linked GH issue. Whether the costs are worth the benefit is a question you are all certainly better equipped to determine than me. Some of these tips are one-offs: for example, once you have a security policy, there's likely nothing else to do in that regard. However, others offer more continuous monitoring in case there's an accidental slip-up: if any new workflows are added to the project in the future without minimal permissions or without pinning dependencies, for example, the Action will update the Security Dashboard with an alert. I'd be happy to submit a few PRs to implement the changes I can. What would forcing maintainers to go through a PR and review process for > the types of changes that normally get pushed directly to master provide? A > way for third parties to weigh in? Can't they already do that through the > mailing list, issues, and PRs? > Code review is simply a means of getting an extra pair of eyes on any new code. Be that to perhaps identify bugs, typos, missed edge-cases or actual malicious activity as seen last year. It does, however, undoubtedly have associated costs (crucially, volunteer time). As I stated above, the cost-benefit analysis is best done by you all who have much more experience with the project. Thank you, Pedro
