Extend GHA integration to support pull_request_target events

[maxrake]

Overview

Is your feature request related to a problem? Please describe.

The current GitHub Action (GHA) integration is limited to pull_request events only. It does not support pull requests from forked repos (e.g., pull_request_target events). This was considered acceptable as the Phylum GitHub App was promoted as the primary option for GitHub users. However, the action now supports manifests in the form of lockfile generation while the app does not. That means more users are going to turn to the action and will want it to work in more environments than simply internal pull requests.

Describe the solution you'd like

Add support to the GHA for PRs, regardless of where they originate.

Describe alternatives you've considered

N/A

Additional context

The pull_request_target event appears to have the same webhook event payload as the pull_request event. This should allow for simple inclusion, but further investigation and testing is needed to uncover any differences.

Acceptance criteria

• pull_request_target events are supported
• Documentation is updated

[marvin-hansen]

I fully support this feature because it allows to scan new pull requests from forked repositories before merge thus preventing sneaking in malware through poisoned dependencies.

This will be a very meaningful contribution to the overall security and credibility of open source projects.

Once this has been completed and tested, I recommend presenting this at appropriate conferences to promote the best practice of supply chain security analysis of all incoming pull requests.

[kylewillmon]

• Branch pipelines are enabled with push events
• pull_request_target events are supported

These are two very different use cases. I fully support allowing pull_request_target events. But I am completely opposed to allowing push events. Can we split this into two separate issues to avoid cluttering the discussion?

[maxrake]

Can we split this into two separate issues to avoid cluttering the discussion?

Done. This issue has been updated and #332 has been created to split the two.

[marvin-hansen]

@kylewillmon @maxrake

I want to elaborate the underlying case for PR protection in more detail.

First of all, I do OSS as a side gig and my real job is building up my company. However, since OSS supply chain security bugs me already for three months, I want to take the time to write down the exact problem I struggle with and why PR protection matters so much not only to me, but the wider OSS community.

As an OSS maintainer, I have limited time, therefore I automate the crap out of it with GH actions. I think only very few small OSS projects have a full-time maintainer therefore time-to-value is really important. For every one GH action I use, there are at least 3 to 5 that were deleted because something didn’t work and when it takes too much time to fix, then it’s not worth the hassle. When there is a better working alternative, I take it immediately and never look back,

After my project got accepted into the Linux Foundation, I had to implement all the OSS security best practices, which btw, is a lot and took me a few weeks to complete. Among others, I had to deploy a lot of preventive security measures, and again, GH action automation to the rescue. That way, I already scan every incoming pull request for known security vulnerabilities, accidentally leaked API or SSH keys, and statically check for unused or outdated dependencies.

For supply chain security, there is a very real ongoing threat with even Microsoft falling victim to it. And if it that isn’t bad enough, there is already the first known OSS supply chain attack against the banking sector. Since a lot of OSS projects aren’t super well managed by volunteers (who have a full-time job, family, and a life), it’s not too hard to imagine that a bad actor submits a PR with malicious code hidden in modified (typo-squatted) dependencies. A code reviewer would almost certainly spot clear exploit code, but probably never even consider checking an innocent looking API call to a generic looking network lib dependency.

Likewise, any normal developer already has enough on his/her plate to do any given day, so he/she may accidentally grabs a typosquatted lib, but when the resulting PR to origin is submitted, this clearly need to bounce to prevent harm before in can happen.

The problem, though, the more advanced the security requirements, the less OSS friendly players are around. Sure enough, for big companies, big money buys you virtually anything, but somehow the security companies don’t like OSS too much so there is no real free alternative available.

However, there is real opportunity. Take the PyTorch project as an example, today (Oct/18/2023) they have over 800 open PR's. Full security scan needs to happen on GitHub for every incoming PR so that lemons get bounced & closed immediately. One less PR to worry about is already something if you have another 800 in the queue. I would suggest offering the PyTorch project free help to setup PR protection in exchange for a blogpost since PyTorch is by far the most widely used ML framework out there so the entire Ai industry may notice you.

In line with the famous Milkshake Marketing, I am not here for a GH action, to the contrary. My job is to protect my repo from increasingly sophisticated supply chain attacks.

My job to be done is simple:

Help me to protect my repo by scanning every incoming PR.

All I am looking for is peace of mind so I can focus on my work.

In terms of messaging, I would strongly prefer something that connects the value of your solution to my actual problem. For example:

Phylum protects your codebase against increasingly sophisticated attacks, so you feel peace of mind while focusing on your work.

Src: How to Write a Great Value Proposition

The moment I read something like this in a Readme, in a repo, a blog, an email, or somewhere else, I am sold before even having made a decision because the message tells me that finally somebody understand the problem I have and therefore, using the solution is a complete no brainer with all the other alternatives already ruled out. It is a known fact that decisions are made long before you even know it.

I wish software security companies would understand this and delivery products I can deploy to my OSS repo in five to ten minutes and when things go well, look at their commercial offering to see if there is something in for my company.

I wrote this down today to give you the clearest possible picture of how this single feature affects OSS maintainers life, and by implication the wider tech industry that relies so heavily on OSS projects in their commercial offerings.

Also, I clearly see the progress, and I want to thank everyone involved to make PR protection the new gold standard for supply chain security.