Repository navigation
Block merges when pull requests introduce exposed secrets #194
Description
🤖 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.
- The earlier ruleset inventory is historical; rebind the complete current ruleset universe before adoption.
- 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_typesscope 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_resolutionthrough the reviewed declarative path when supported, otherwise use the documented API/settings path and record the remaining GitOps gap under Adopt supported GitHub rulesets and track remaining provider gaps #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 supported GitHub rulesets and track remaining provider gaps #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 still lacks the secret-scanning alert-resolution rule and parameters | upstream | last-verified 2026-10-17: not shipped — latest release is still v0.20.0 (2026-08-25) and main is still 0609e5fcca24d0f737c8cd9c6b4a39439f51f3ba, both inspected on 2026-10-08 without the rule; upstream has no issue tracking it. Provider support or an approved adapter and native merge-blocking controls remain required.
Activity
[-][feature]: Add org wide ruleset for https://github.blog/changelog/2026-09-09-block-pull-requests-with-exposed-secrets-from-merging/[/-][+]Block merges when pull requests introduce exposed secrets[/+]devantler commentedon Sep 19, 2026
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 throughprovider-upjet-github. The version running in production (v0.19.1) supports these rule kinds on anOrganizationRuleset: 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
rulesschema carries the new field, then add a managedrequire-secret-scanning-alert-resolution.yamllimited 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
devantler commentedon Oct 2, 2026
Refreshed the approved upstream inspection on 2026-10-02. The latest released provider is v0.20.0. Its served OrganizationRuleset schema supports required code scanning but has no secret-scanning alert-resolution rule field. A provider upgrade alone therefore does not deliver this issue.
Blocker: released declarative provider support remains absent. Recheck the served schema when a supporting release appears, then implement the managed rule and its acceptance checks. This is released-source evidence, not a claim about the deployed provider version; no imperative ruleset was introduced.
devantler commentedon Oct 3, 2026
Completed the active repository and inherited-ruleset inventory with a second full read. The organization census, security-setting observations, conditions, rule parameters and bypass lists were stable across the repeated join. Detailed findings remain in private operator evidence.
This supplies the inventory step needed before selecting a target policy. Enabled scanning alone is not proof of the entitlement required by GitHub’s preview announcement. Entitlement verification, provider support or an approved adapter, maintainer-approved scope/bypasses, and native merge controls remain required. No policy was changed.
devantler commentedon Oct 3, 2026
The authorized provider inspection confirms the schema blocker at both latest release v0.20.0 (
a211e095e2fe49c477836acec2ad4a28aa60e030) and current main (0609e5fcca24d0f737c8cd9c6b4a39439f51f3ba). The four OrganizationRuleset/RepositoryRuleset CRDs, across namespaced and cluster-scoped variants, are unchanged between those revisions and expose no corresponding secret-alert-resolution rule or secret-type parameters. Released provider schemas.GitHub’s native preview merge rule exists, but the owned declarative path cannot express it through these provider schemas. This is an unsupported-schema finding; current write-credential availability was not tested, and no permission denial or active merge protection is inferred. No upstream contribution or imperative configuration change was made.
Keep this issue open for provider support or an approved declarative adapter, eligibility/scope and bypass decisions, real positive/negative merge controls, and live readback/drift proof. This refresh resolves the inspection uncertainty; it does not deliver or waive the enforcement gate.