Hi @alexshtin!
That’s a good question, and we’re still figuring out what the best answers are!
Most of the users, included ourselves, enable read-only public access for a pipeline, and not building third-party forks.
On a pipeline with a GitHub repository, in the pipeline settings, you can tell it not to build pull requests from third parties (forks). Then you can manually trigger builds if a change doesn’t look malicious.
f you do want to build forks but want to have a manual review step, all branch names will be prefixed by the fork username, so instead of BUILDKITE_BRANCH=“master” it might be BUILDKITE_BRANCH=“user:master”. You can detect these on your agents using a pre-command hook, or something similar which can’t be modified by the committer and pipeline upload a block step so that a trusted user can vet the code before allowing the build.
You can also use the agent’s environment hook to add strict checks for what repositories, commands, and plugins are allowed to run. You can learn more about that here.
Secrets are tricky. Any build running on your infrastructure will have access to any secrets within the build environment. So it’s best not to run untrusted code without reviewing it first.
There was also a good suggestion from another user in the forum, it’s a workaround but that could probably help you.
Hopefully that gives you some options!
Cheers,