Introduction

Yes, it is okay to use GitHub Secrets with a public repository, but only if you understand the execution model of GitHub Actions and design your workflows around it. The secrets themselves are not automatically public just because the repository is public. The risk comes from how workflows are triggered, what code gets to run with those secrets, and whether your jobs can leak them through logs, artifacts, or untrusted pull requests.

What GitHub Secrets Actually Protect

GitHub repository secrets are encrypted values that workflows can access at runtime.

A basic example looks like this:

1jobs:
2  deploy:
3    runs-on: ubuntu-latest
4    steps:
5      - uses: actions/checkout@v4
6      - run: echo "Deploying"
7        env:
8          API_TOKEN: ${{ secrets.API_TOKEN }}

The value is not stored in the repository code and is masked in logs in many ordinary cases. That is useful in both private and public repositories.

So the existence of a public repo does not automatically make repository secrets unsafe.

Where the Real Risk Comes From

The danger appears when untrusted code can execute in a workflow that has access to secrets.

Typical risky situations include:

• a workflow triggered by untrusted pull request code
• printing secret-containing environment variables directly
• passing secrets to scripts that echo too much debug output
• using long-lived cloud credentials where short-lived identity would be safer

The most important question is: who can cause a job with secrets to run, and what code executes inside that job?

Public Repos and Pull Requests

In public repositories, external contributors can open pull requests. GitHub protects you by not exposing repository secrets to workflows triggered from forks in the normal pull_request case.

That is a crucial safety boundary.

However, if you use workflow patterns such as pull_request_target incorrectly, or check out and run untrusted PR code in a job that has secrets, you can defeat that protection yourself.

So the correct answer is not just "secrets are safe". It is "secrets are safe if you preserve GitHub's trust boundaries and do not bypass them accidentally."

Better Patterns for Public Repositories

For public repos, strong patterns include:

• use secrets only in trusted branches and protected deployment workflows
• keep CI for untrusted pull requests separate from deployment jobs
• require approvals for sensitive environments
• prefer short-lived cloud credentials through OIDC instead of long-lived static keys

For example, test jobs on pull requests can run without secrets, while deploy jobs run only on pushes to main or on manually approved releases.

on:
  push:
    branches: [main]

That separation reduces the chance that public contributions ever execute secret-bearing jobs.

Secrets Are Not a Full Security Strategy

Even when GitHub stores secrets correctly, you still need to manage blast radius.

Good practice means:

• least-privilege tokens
• environment-specific secrets
• regular rotation
• auditing workflow logs and permissions
• avoiding secrets entirely where federated identity works better

If a secret only grants narrow deployment access to one environment, accidental exposure is much less damaging than if it is a global administrator credential.

OIDC Is Often Better Than Static Secrets

For cloud deployments from GitHub Actions, short-lived credentials via OpenID Connect are often safer than storing permanent cloud keys as secrets.

That shifts the model from:

• store long-lived AWS, Azure, or GCP credential in GitHub

into:

• let GitHub Actions prove its identity to the cloud provider
• receive short-lived credentials for that one run

In a public repository, that is often a much better production posture.

Common Pitfalls

The most common mistake is assuming a secret is safe no matter what code runs in the workflow. If untrusted code runs with secret access, the workflow design is the problem.

Another mistake is using pull_request_target without understanding that it can run in a more privileged context than ordinary forked pull request workflows.

Teams also often over-trust masking. GitHub masks many obvious secret exposures, but masking is not a substitute for good workflow isolation.

Finally, avoid storing powerful long-lived production credentials when a shorter-lived or narrower-scoped alternative exists.

Summary

• GitHub Secrets can be used safely in public repositories if workflows are designed carefully.
• The key risk is untrusted code executing in jobs that can read secrets.
• Keep secret-bearing jobs restricted to trusted branches, environments, or approved deployments.
• Be especially careful with pull request workflows and pull_request_target.
• Prefer least-privilege credentials and, where possible, short-lived identity-based access instead of static secrets.