Reuse policy, not copy-paste

Reusable workflows centralize permissions, provenance, and common release behavior. Keep application workflows short enough to understand at a glance.

permissions: { contents: read, id-token: write }
jobs:
  verify:
    uses: org/.github/.github/workflows/verify.yml@v1

References

  • GitHub Actions security hardening documentation

Design the pipeline as a trust boundary

CI has access to source code, build outputs, and often cloud credentials. Treat every workflow as production infrastructure. Pin third-party actions to reviewed commit SHAs where possible, keep the default token read-only, and grant additional permissions to one job rather than an entire workflow. Prefer workload identity for cloud deployment so that no long-lived secret needs to sit in a repository setting.

Reusable workflows are especially useful for release policy. A single maintained workflow can enforce provenance, dependency scanning, permissions, and deployment approval while application repositories retain a short, readable call site. That gives teams consistency without burying their delivery logic in a monolith.

Review checklist

  • Does untrusted pull-request code receive a write-capable token?
  • Are artifacts and releases traceable to a commit and a build?
  • Is the deployment environment protected by an approval where appropriate?
  • Can an owner explain every secret exposed to the job?

Further reading: GitHub Actions security hardening.