[FEAT]: Resources to attach code security configurations to repositories and set org/enterprise defaults

[casey-robertson-paypal]

Describe the need

The github_organization_security_configuration and github_enterprise_security_configuration resources being added in #3284 (and the matching data sources tracked in #3505) manage/read the configuration object only. They do not cover the two remaining lifecycle operations needed to actually roll a configuration out:

1. Attaching a configuration to repositories.
2. Setting a configuration as the default for newly created repositories.

Today those are only doable via the REST API or gh, so a fully Terraform-managed org-wide rollout isn't possible even after #3284 + #3505 land. This proposes resources to close that gap.

Proposed resources

Two resources per scope (org + enterprise), keeping each declarative and round-trippable:

• github_organization_security_configuration_repositories — binds a configuration to an explicit set of repositories.
  • Inputs: configuration_id (required), repository_ids (required list).
  • Read/refresh via ListCodeSecurityConfigurationRepositories; drift-detects add/remove.
• github_organization_security_configuration_default — sets the org's default for new repos.
  • Inputs: configuration_id (required), default_for_new_repos (all | none | private_and_internal | public).
• github_enterprise_security_configuration_repositories / github_enterprise_security_configuration_default — enterprise equivalents.

Design note — why explicit repository_ids rather than exposing the API's scope verb: the attach endpoint's scope=all attaches only repositories that exist at call time; repositories created afterward are governed by the default setting, not by a prior all attach. Modeling attach as scope=all would therefore perpetually drift as new repos appear. An explicit repository_ids list round-trips cleanly against the list endpoint, and new-repo behavior is expressed through the separate _default resource. Open to modeling scope as an alternative/among-other input if maintainers prefer — flagging the drift tradeoff up front.

SDK support

The wiring already exists in the vendored SDK (go-github v88), so this is a resource-authoring task, not an SDK gap:

• OrganizationsService.AttachCodeSecurityConfigurationToRepositories(ctx, org, configurationID, scope, repoIDs)
• OrganizationsService.SetDefaultCodeSecurityConfiguration(ctx, org, configurationID, newReposParam)
• OrganizationsService.ListCodeSecurityConfigurationRepositories(...) (read side)
• Identical EnterpriseService trio.

Underlying REST: POST /orgs/{org}/code-security/configurations/{id}/attach, PUT /orgs/{org}/code-security/configurations/{id}/defaults, GET /orgs/{org}/code-security/configurations/{id}/repositories (and /enterprises/{enterprise}/... equivalents).

Notes

Tracking separately from #3284 to keep the resource PR focused, per the maintainer's preference (same rationale as #3505). Happy to open the PR once the configuration resources land. Relates to the broader ask in #2043.

Code of Conduct

• I agree to follow this project's Code of Conduct

[github-actions]

👋 Hi, and thank you for opening this issue!

This repo is maintained by GitHub and community members on a best-effort basis. We'll get to this as soon as we can.

You can help us prioritize by adding details, reproduction steps, or a 👍 to issues that matter to you, and by joining the discussion on open issues and PRs.

---

_{🤖 This is an automated message.}

[casey-robertson-paypal]

One clarification on the attach resource's inputs, from a real-world org-wide rollout driving this need:

The most common operation is "attach this configuration to all repositories" (or all public / all private_or_internal) — i.e. the API's scope parameter, not an enumerated repository list. Enumerating hundreds of repo IDs into config (or a data source) just to express "all" is awkward and drifts as repos are created/archived.

So I'd suggest the resource support scope (all | all_without_configurations | public | private_or_internal | selected) as a first-class input, with repository_ids used only when scope = selected. That mirrors AttachCodeSecurityConfigurationToRepositories(ctx, org, configurationID, scope, repoIDs) in go-github directly.

The steady-state caveat still stands and is worth documenting on the resource: scope = all attaches repos existing at apply time; repositories created afterward are governed by the default (the separate _default resource), not by re-running all. Reads via ListCodeSecurityConfigurationRepositories reflect actual attachments regardless of how they were attached, so import is clean either way.

Happy to implement it this way when the resources land.