Plugin Directory: Block a release when a security scan reports a high risk score

[obenland]

Security scan callbacks now include a max_risk_score (0–10) and a bounded findings array. This builds on the advisory integration and acts on that evidence.

Builds on #779. Supersedes the scan-driven half of #720/#729.

What it does

• A completed scan with max_risk_score >= 8.0 (Plugin_Scan_Gandalf::BLOCK_RISK_SCORE, filterable) blocks the scanned release via Plugin Directory: Add an API to block a release from being served #785's API_Update_Updater::block_release(), regardless of the plugin's install count: the version is held out of the update API — the previously served version keeps being served — until a reviewer force-releases it. The plugin itself stays published; nothing closes.
• A verdict that can't un-ship anything — the version is already being served, or a newer release superseded it mid-scan — blocks nothing and stays advisory; the alert still carries the risk score for manual action.
• The review team receives the findings as context: an internal note on the plugin (bold risk score and title per finding, file location on the next line), a Slack alert, and an evidence snapshot in post meta bounded to the ten highest-risk findings (all that ever surface). Blocks always alert; below-threshold results stay advisory and deduplicate as before.

Callback handling

• Contract validation lives in Plugin Directory: Validate the security scan callback contract at the route #787; the reported max_risk_score is trusted as-is — the scanner is authoritative for it.
• Consumed callbacks are recorded per scan_id under a canonical (key-order-insensitive) digest: an identical retry is acknowledged without repeating effects, a different body for a consumed scan is rejected as a conflict, and a completed verdict supersedes an earlier failure report for the same scan — the pending entry survives a failure for exactly that reason. A short per-plugin lock (released even if processing throws) prevents concurrent callbacks from double-processing or clobbering each other's records.
• Finding strings are treated as untrusted and escaped per output context: esc_html() for the wp-admin note, htmlspecialchars( …, ENT_NOQUOTES ) for Slack (the idiom of the existing Slack integrations — Slack only decodes &/</> entities).

Testing

tests/Security_Scan_Block_Test.php (20 tests) covers the threshold boundary, replay and conflict handling (including a re-marshalled retry with different key order), a completed verdict superseding a failure report, blocking refused for served and superseded versions, blocking independent of install count, a reported score blocking even without findings detail, the snapshot bound, escaping of hostile finding strings, the row holding the served version through a scan-driven block, and force-release closing the loop.

🤖 Generated with Claude Code

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[github-actions]

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

Core Committers: Use this line as a base for the props when committing in SVN:

Props obenland.

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.