Block merges when pull requests introduce exposed secrets

[devantler]

🤖 Generated by the Agentic Engineer

Objective

Prevent an eligible pull request from merging until secret scanning has completed for its current head and every secret-scanning alert introduced by that pull request is resolved.

Context

GitHub added the public-preview ruleset type require_secret_scanning_alert_resolution on 2026-09-09. It complements push protection by enforcing a second control at merge time.

Current verified evidence for devantler-tech/monorepo:

• Secret scanning, push protection, validity checks, non-provider patterns, and AI detection are enabled.
• Open secret-scanning alerts are zero.
• None of the 13 applicable active branch rulesets contains the new rule.
• Portfolio-wide eligibility and ruleset coverage have not yet been completely joined.

References:

• https://github.blog/changelog/2026-09-09-block-pull-requests-with-exposed-secrets-from-merging/
• https://docs.github.com/en/code-security/concepts/secret-security/secret-scanning
• https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/managing-rulesets/about-rulesets

Desired state

An organization or repository ruleset targets every eligible active portfolio repository and requires secret-scanning alerts introduced by a pull request to be resolved before merge. Provider-secret patterns are the initial floor. Generic and custom patterns are included only after their false-positive behavior is measured. Bypass actors remain minimal, explicit, and reviewed.

Acceptance criteria

• Inventory every active, non-archived portfolio repository and record whether GitHub Secret Protection or GitHub Advanced Security makes the merge rule available.
• Rebind all applicable branch rulesets and confirm there is no equivalent active rule before creating another.
• Decide the initial secret_types scope from measured signal; provider patterns are mandatory, while generic/custom categories require false-positive evidence.
• Define the exact target branches and repositories without widening coverage to archived repositories.
• Record every bypass actor and the reason it is required; no implicit administrator bypass.
• Add require_secret_scanning_alert_resolution through the reviewed declarative path when supported, otherwise use the documented API/settings path and record the remaining GitOps gap under Adopt remaining rulesets declaratively as provider-upjet-github gains support (10 org rulesets + push + Actions policies) #69.
• Validate with an approved non-sensitive fixture that the scan must finish and a newly introduced alert blocks merge until resolved.
• Verify ordinary clean pull requests and required automation still merge normally.
• Read back the active ruleset, its targets, parameters, and bypass actors through the GitHub API.
• Add drift coverage so removal or weakening of the rule fails the repository-governance check.
• Document rollback and alert-remediation ownership.

Dependencies

• Parent epic: Adopt remaining rulesets declaratively as provider-upjet-github gains support (10 org rulesets + push + Actions policies) #69
• Requires organization-administration authority for the final ruleset mutation.
• Ruleset scope and bypass identities require maintainer approval before enforcement.

Notes

Keep public evidence at desired-state and checklist level. Do not publish real credentials, exploitable test values, or private alert details.

Blocker: crossplane-contrib/provider-upjet-github OrganizationRuleset lacks a secret-scanning alert resolution rule | upstream | last-verified 2026-09-19: absent from the deployed v0.19.1 CRD schema

[devantler]

🤖 Generated by the Agentic Engineer

Parked on a named upstream blocker: the org-ruleset tooling cannot express this rule yet.

Org rulesets here are managed as code in deploy/organization-rulesets/, reconciled by Crossplane through provider-upjet-github. The version running in production (v0.19.1) supports these rule kinds on an OrganizationRuleset: branch/tag name patterns, commit metadata patterns, creation, deletion, update, non-fast-forward, pull request, required code scanning, linear history, signatures, status checks and workflows. There is no secret-scanning alert resolution rule. That rule type went into public preview on 2026-09-09, and the provider's upstream Terraform provider has not exposed it yet.

Creating the ruleset by hand through the REST API would work today, but it would sit outside the managed set and drift from the declared state. So this waits for provider support rather than taking a manual shortcut.

Next step when it clears: bump the provider, confirm that the CRD's rules schema carries the new field, then add a managed require-secret-scanning-alert-resolution.yaml limited to provider-secret patterns, as the desired state above describes.

Blocker: provider-upjet-github OrganizationRuleset lacks a secret-scanning alert resolution rule | upstream | last-verified 2026-09-19: absent from the deployed v0.19.1 CRD schema