Versions
The Secrets Blueprint workflows pin SOPS 3.13.3 and reference every GitHub Action by its full commit SHA. The repository contains no OpenTofu or Terragrunt code of its own: the KMS keys and the syncer role it uses are part of the AWS Baseline and follow the Baseline's pins.
Where the pins live
Both workflows set SOPS_VERSION in their env block and download that exact release in an install step. The two workflows carry the same pins, so the pull-request check and the sync decrypt with the same SOPS.
Tools
| Tool | Version | Where it runs |
|---|---|---|
| SOPS | 3.13.3 | Both workflows, installed in each job |
| yq | Latest release at run time | Both workflows, installed in each job |
| AWS CLI | Version 2 | The runner image; required by the sync script |
Engineers who edit secrets on their own machines need sops and yq locally, and an AWS sign-in through IAM Identity Center.
GitHub Actions
| Action | Version | Used by |
|---|---|---|
actions/checkout | v7.0.1 | Both workflows |
aws-actions/configure-aws-credentials | v6.3.0 | Both workflows, OIDC sign-in |
actions/github-script | v9.0.0 | The plan workflow, PR comment |
Each is referenced by its full commit SHA with the version in a comment, so a moved tag cannot change what runs.
Runners
Jobs run on GitHub-hosted ubuntu-latest runners by default. A repository variable can point them at self-hosted runners instead, the same switch the other BuiltForProd workflows read.
Keys
The four SOPS keys are symmetric AWS KMS keys with automatic annual rotation turned on. Rotation replaces the key material without changing the key or its alias, so encrypted files in Git stay readable and .sops.yaml never changes. See KMS for how rotation works.
How versions change
A version change is its own pull request against the workflows, reviewed by the platform leads or infrastructure admins who own .github/. The policy is on the versioning policy page, and the versions across all BuiltForProd repositories are in the release notes.