A security manager must guarantee that, across many repositories in an organisation, no pull request can be merged into the default branch while code scanning has an open alert above a chosen severity, and the rule must apply to repositories created in future without an administrator configuring each one. Which control enforces this consistently across the suite of repositories?
- AA per-repository branch protection rule on the default branch that requires the code scanning status check to pass, configured by each repository administrator.
- BAn enforced security configuration applied to the repositories, which enables code scanning and therefore blocks merges whenever an alert above the chosen severity is open.
- CA required workflow that runs the code scanning analysis on every pull request, so the merge is blocked until the workflow reports no alerts above the threshold.
- DAn organisation-level ruleset targeting the default branch that adds a code scanning merge protection rule with the required alert severity threshold, applied across the targeted repositories. Correct
Why A is wrong: Branch protection can require a code scanning check, so this looks like the right gate, but it is configured per repository by administrators and does not apply automatically to future repositories, allowing drift and gaps. It cannot give the organisation-wide, automatically applied guarantee the security manager needs.
Why B is wrong: A security configuration is the right tool for enabling and locking code scanning across repositories, which makes it tempting here, but it governs feature enablement rather than merge gating and does not itself block pull requests on alert severity. The merge-blocking behaviour comes from a ruleset or branch protection, not from the configuration.
Why C is wrong: A required workflow can force an analysis to run, which is why this seems to gate merges, but completing the scan is not the same as blocking on open alert severity, and a passing workflow run can still coexist with open alerts. The severity-based merge gate is the code scanning merge protection rule, configured through a ruleset.
Why D is correct: Organisation-level rulesets can target the default branch across many repositories at once and include a code scanning merge protection rule with a configurable alert severity, blocking merges while qualifying alerts are open. Because the ruleset is defined once at the organisation and matches repositories by pattern, it covers repositories created later without per-repository setup.