Creating secret.yml for github-well-architected

[vault-chatops]

This pull request was automatically generated from vault-chatops.
It contains the secrets.yml file for github-well-architected in staging.

More info about this file can be found here

Please review these files and add missing information if possible.

These are the most important keys in the secrets.yml file:

key

This specifies the key in vault if it's not the same as the key for this secret

type

The type of secret. This is used to determine how the secret is used in the application.
Some secrets are just configuration. In that case the type is config and the keys owner, playbook and externally_usable can be left out.
For values like usernames that are used to authenticate, but are not a secret, the type credentials should be used.
A list of available types can be found here

owner

Which team owns the usage of the secret, not the central management service. If you are part of the sae-ps team, and the secret is a database credential your team uses, then you put in @github/sae-ps

playbook

Is there a playbook for rotating this secret? If so, please provide a link to it.

externally_usable

If this secret is leaked can it be used without GitHub network access? (like a GitHub PAT)

kind

This should probably be set to latest_at_deployment_start.

[github-actions]

Dependency Review

✅ No vulnerabilities or license issues or OpenSSF Scorecard issues found.

Scanned Files

None

[well-architected-sync-bot]

✅ Site Deployment Request Submitted

A request for live site deployment has been submitted.

Next Steps

1. GitHub site maintainers will review your request shortly.
2. Once approved, the changes will be deployed to the GitHub Well-Architected live site.
3. This PR will be merged once the deployment is successful.

Note: If this contribution involves collaboration with GitHub, please contact your GitHub representative to help expedite the deployment process.

---

Internal xref:

[Copilot]

Pull request overview

Adds a MODA secrets.yml for the github-well-architected staging environment, defining Vault-backed secret metadata for deployment/runtime configuration.

Changes:

• Introduces config/moda/secrets/staging/secrets.yml with initial secret entries for Copilot-related URLs and an HMAC key.
• Sets kind: latest_at_deployment_start on all entries.

Comments suppressed due to low confidence (2)

config/moda/secrets/staging/secrets.yml:23

• CSE_COPILOT_SERVICE_URL also has empty type, owner, and externally_usable fields. Please populate these with valid values (or, if it’s purely configuration, set type: config and remove/omit the extra keys) to avoid invalid/ambiguous secret classification.

  CSE_COPILOT_SERVICE_URL:
    key: CSE_COPILOT_SERVICE_URL
    type:
    owner:
    playbook: ''
    externally_usable:
    kind: latest_at_deployment_start

config/moda/secrets/staging/secrets.yml:30

• The kittens entry looks like placeholder/non-production data and is missing/invalid metadata (type: kittens, empty owner, and empty playbook). If this is not a real secret, it should be removed; if it is real, please update it to use a valid type, add the owning team, and provide a playbook (or omit playbook if type: config).

  kittens:
    key: kittens
    type: kittens
    owner: ''
    playbook:
    externally_usable: false
    kind: latest_at_deployment_start

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

You can also share your feedback on Copilot code review. Take the survey.

[Copilot]

COPILOT_API_URL has empty required metadata fields (type, owner, and externally_usable). Please either set type to an appropriate value (e.g., config if it’s just configuration) and then omit the non-applicable keys, or fill in all required fields with valid values so this entry passes schema/lint validation.

This issue also appears in the following locations of the same file:

• line 17
• line 24

[Copilot]

Empty fields are represented inconsistently (playbook: '' in some entries vs playbook: in kittens). Please use a consistent representation (prefer omitting optional keys or setting them to an explicit value) so downstream tooling doesn’t interpret empty string vs null differently.

Suggested change

	playbook:
	playbook: ''