Deployment secrets and permissions

Protects build and deployment credentials through least-privilege identities and separation from untrusted code paths.

secrets-deployment-permissions

Team members using this skill

See how it helps

When is it useful?

Use it when configuring cloud authentication, CI permissions or secret delivery for pull requests and releases.

What does it help you do?

Limits CI identities and prefers scoped workload authentication.
Separates environment secrets from untrusted pull-request code.
Pins third-party actions and validates missing-secret configuration.

Try asking this

Review deployment credentials so a forked pull request cannot access production secrets. Run an untrusted pull-request build with a harmless secret-access probe. It must receive no production identity, while the authorized deployment job retains its narrow scope.

Detailed documentation

Read the skill’s original instructions, examples and checks in their authored language.

Details…Show less

Secrets & Deployment Permissions

CI/CD runners and deployment pipelines hold the keys to production infrastructure and registries. Apply least privilege, short-lived credentials, and strict trust boundaries to every workflow job.

Least-Privilege Pipeline Identities

Default permissions: contents: read:
- Set workflow-level permissions: { contents: read } (or empty {}) by default, and grant elevated permissions (packages: write, id-token: write, deployments: write) only on the specific job that publishes or deploys.
Prefer Workload Identity / OIDC over long-lived static cloud keys:
- Authenticate CI jobs to AWS, Google Cloud, Azure, or npm/PyPI trusted publishers using short-lived OIDC tokens (id-token: write) scoped to a specific repository, environment, and branch/tag claim (ref:refs/heads/main) rather than storing non-expiring admin keys in CI secrets.
Environment-scoped secrets & approval gates:
- Store production credentials in protected CI Environments (environment: production) with branch protection rules and required reviewers, isolated completely from staging and PR check runners.

Supply-Chain & Untrusted Code Defenses

Threat Vector	Vulnerable Pattern	Mandatory Hardening
Untrusted Fork / PR Execution (`pull_request_target`)	Running `pull_request_target` and checking out/executing the PR's head commit with access to repo secrets	Never run `npm install`, build scripts, or tests from an untrusted PR head inside `pull_request_target`. Use unprivileged `pull_request` workflows for code checks.
Script Injection in Workflow `run:` Blocks	Interpolating untrusted context directly in shell: `run: echo "${{ github.event.issue.title }}"`	Pass untrusted values through `env:` variables (`TITLE: ${{ ... }}`) and reference `"$TITLE"` safely in the shell script.
Mutable Third-Party CI Actions / Orbs	Referencing external actions by floating branch or tag (`uses: some-org/action@main` or `@v1`)	Pin third-party actions to a full 40-character commit SHA (`uses: org/action@a1b2c3... # v1.4.2`) and audit their permissions.
Secret Leakage in Logs & Artifacts	Running `env`, `printenv`, `set -x` around secret variables, or passing secrets via `--build-arg` in Dockerfiles	Never use `DOCKER --build-arg` for secrets (they persist in `docker history`); use BuildKit `--secret` mounts (`RUN --mount=type=secret,id=...`). Mask dynamic tokens before logging.

Secret Rotation & Zero-Secret Source Invariants

Never commit .env files, private signing keys (.p12, .keystore, .pem), or service-account JSON files to git. Provide a documented .env.example with safe placeholder values and startup validation that fails fast with a clear message naming any missing required secret.

Included files 1

SKILL.md