Circleci Build Forked Pull Requests
To circleci build forked pull requests, turn on the project setting that runs external builds. You should also block secret keys from passing into those untrusted fork jobs. Many teams turn on fork builds so external coders can test code changes fast. If teams share broad permissions with forks, untrusted code can steal sensitive keys. How to circleci build forked pull requests in your pipeline A forked pull request comes from a copy of your code owned by someone else. The platform listens fo
Pull Request Security Checks + CircleCI Security: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
To circleci build forked pull requests, turn on the project setting that runs external builds. You should also block secret keys from passing into those untrusted fork jobs. Many teams turn on fork builds so external coders can test code changes fast. If teams share broad permissions with forks, untrusted code can steal sensitive keys.
How to circleci build forked pull requests in your pipeline
A forked pull request comes from a copy of your code owned by someone else. The platform listens for a webhook event from your source code host. When a user opens a pull request, the source host sends a webhook payload. The build server reads this event and checks your project rules for forks. If fork builds are off, the server drops the request and runs nothing. If fork builds are on, the server spins up a fresh build machine. It pulls the code from the external fork and merges the target branch. Then it runs the steps defined in the pipeline file inside that branch. The pipeline file lives in the code, so the fork owner can edit it. Because of this, the platform blocks project secrets from loading by default. The job runs with read-only access to public code and outputs test results.
What native fork rules solve and what they leave open
Native fork settings solve the basic problem of running public tests without leaking secrets. By hiding secret variables from forks, the tool stops easy key theft in builds. Still, this binary rule creates a hard choice for your engineering team. Many test suites need live database sessions or cloud keys to run full checks. If you block all secrets, those integration tests fail on every external pull request. To fix this, some teams turn on the setting that shares secrets with forks. Once a job has a secret key, the platform cannot control what runs next. An attacker can edit the build file to print keys into the build log. They can also send stolen keys to an external server during the test run. Native settings decide if a job gets a key, not what commands do. Even with manual approval workflows, reviewers might miss a hidden script in a pull request. The build runner executes every command inside the job with full key permissions.
Managing secret exposure in external contributor workflows
Teams can split their pipeline into two separate stages to lower this risk. The first stage runs unit tests and linters that need zero secret keys. This stage runs on every forked pull request right when it opens. The second stage runs integration tests that need real database sessions or cloud roles. Teams hold this second stage behind a manual approval step in the workflow. A trusted team member must read the code diff before clicking the approval button. Only after a human checks the code does the job get the needed secrets. Still, human code review can miss clever tricks hidden inside build scripts or packages. Once the approved job starts, the runner gives full role permissions to the script. If a test queries user tables, raw emails or card numbers can enter logs. Masking rewrites matched fields like phone numbers or national IDs in query results. Without query level checks, any approved build job can still run bad commands.
Pull Request Security Checks + CircleCI Security: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
Check database and API queries on the wire
Identity tools, roles, and network rules decide who opens a session. Setup alone cannot check what each query does or mask sensitive values in a response once a session starts. When workflows touch Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes APIs, SSH, or internal HTTP APIs, hoop.dev runs beside those services as an open-source proxy, a sidecar for your Postgres or API. It inspects requests coming in and results going back on the wire.
Your login details and client tools stay as they are while hoop.dev guardrails refuse bad deletes or drops before they run. On responses, hoop.dev data masking rewrites matched sensitive values in memory. Furthermore, hoop.dev holds SOC 2 Type II, is MIT licensed, and writes every query and decision to an audit trail that generates evidence for HIPAA, GDPR, and PCI DSS. See the source on GitHub.
Frequently asked questions
Why do forked pull requests fail when they need secret keys?
The build platform hides secret keys from forked pull requests by default for safety. Any build step that needs an API key or database password will fail.
Is it safe to pass project secrets to forked pull requests?
No, sharing secrets with untrusted forks is unsafe because authors can edit build steps. A bad actor can add a single line to send your keys outside.
How can teams test forked code that needs database queries?
Teams should run basic tests first and require human approval before running database tests. You should also limit what queries the test role can run during the build.