Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:118879
MIME-Version: 1.0
References: <CAFWHjfpriiBX1Xg34F95zXsgwKQeh1-AwActDws5wuRL83pHhQ@mail.gmail.com>
 <CAMrTa2E5VHJGANm0u3Nrs9a9DeoJspE7JAg0902TzDi1Pq4iiA@mail.gmail.com>
In-Reply-To: <CAMrTa2E5VHJGANm0u3Nrs9a9DeoJspE7JAg0902TzDi1Pq4iiA@mail.gmail.com>
Reply-To: Pedro Nacht <pnacht@google.com>
Date: Mon, 24 Oct 2022 14:05:37 -0300
Message-ID: <CAFWHjfr0gFxzqRX12N7u5pWfNkafDeW8Y81d8E==5ibg2_=MiQ@mail.gmail.com>
To: Jordan LeDoux <jordan.ledoux@gmail.com>
Cc: internals@lists.php.net
Content-Type: multipart/alternative; boundary="000000000000e1bc2d05ebcacdae"
Subject: Re: [PHP-DEV] Adding the OpenSSF Scorecards GitHub Action
From: internals@lists.php.net ("Pedro Nacht via internals")

--000000000000e1bc2d05ebcacdae
Content-Type: text/plain; charset="UTF-8"

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

--000000000000e1bc2d05ebcacdae--