To quote the GitHub Branch Source Plugin:

One of the great powers of pull requests is that anyone with read access to a repository can fork it, commit some changes to their fork and then create a pull request against the original repository with their changes. There are some files stored in source control that are important. For example, a Jenkinsfile may contain configuration details to sandbox pull requests in order to mitigate against malicious pull requests. In order to protect against a malicious pull request itself modifying the Jenkinsfile to remove the protections, you can define the trust policy for pull requests from forks.

I have found from experience that often certain users need to be trusted even though they may not have write access to the repository. For example, certain developers may focus on pipeline and CI/CD development and need to be able to modify trusted files (e.g. Jenkinsfile), but they are not necessarily collaborators or admins for the repository.

A simple and effective solution to this problem is to support a new trust mechanism that will check if the fork pull request author is on a whitelist. If they are then they are trusted, otherwise they are not. This could also be used in conjunction with the existing trust mechanisms.