Review test embargo for security issues

Personally I think the 2-month embargo is still fine. Every line of test code we release also gives LLMs more information to reverse-engineer a vulnerability.

We regularly make exceptions to the policy and release the tests on the day of if they don't actually disclose more about the vulnerability than the fix and/or SA themselves. I think a case-by-case basis is still appropriate, where we hold the 2-month embargo by default, but choose to release the tests earlier if there is low risk, an exploit is already in the wild, etc.

What are the advantages of shortening the window? (Excluding a one-off with a contrib maintainer asking about releasing a test earlier, since that has happened once in like a decade-plus of this policy.)

Speaking as a contrib maintainer however I believe most of this should be relevant to core too:

In the past couple weeks I had mulled this over and decided to change my policy to release tests at the same time I release the security fix into the dev branch (I had been waiting two weeks to a month in the past).

This came after evaluating many of the same reasons as @mcdruid raised.

1. Reducing the risk of regression
2. Ensuring developers working on other aspects of the code are better able to understand how their changes interact with the new security release
3. Ensuring tests can apply cleanly without requiring rework
4. Ensure tests do not get left behind (I know I had at least one core issue take over a year for release, I might still have one that hasn't been merged yet)
5. Avoidance of the mental fog of working on old issue
6. The patch code generally already reveals the flaw, either to plain humans or to AI's.
7. Providing more details on Indicators of Compromise to site owner security teams to audit their logs for a possible breach.
8. Realization that when I tag a release at 12 hours before the release is announced by the DST that attackers are already gathering details
9. The full disclosure window is generally shrinking

(No particular order, numbered just in case they need to be referenced in latter messages.)

Almost all of that applies to core IMO, and I've seen several these points missed as devs continue to work on issues putting in changes that are now firmly incompatible with the previous security fix, only realizing this when months later the tests are merged (or when I speak up to warn them).

I also want to put a nod to the IoC side, I frequently reverse engineer the Core/Contrib fix and guess on what I should be looking for in my logs, praying for core to release tests months latter, and if the test don't match my determinations I need to re-run log analysis on the logs to see if I was compromised before applying the patch. Having tests sooner (same day) I would argue makes my site more secure and helps me detect and remove any zero day exploit usage.

The point about attackers having a time advantage is why I've not been planing on including it as part of the tagged security release itself (since it goes public a few hours before the DST announces it) and instead will only include it as part of the dev branch commit after publication.

I will admit a test can give slightly more information than just the fix, however I firmly agree that is a becoming an ever decreasing gap in protection. IIRC on Drupal Slack we were hearing about exploit attempts the day after SA-CORE-2026-004, in all likelihood the exploit attempts started much sooner. Did withholding those tests really make the vulnerability any less effective for attackers? I've so bar been using AI to analyze possible security releases, I've not yet tasked it to try and generate PoC's however that would be a likely future step.

Another item to consider is, how long do vulnerability reporters withhold their PoC's? I'm currently on a 30 day post public release policy (though I'm very much aware my entire 90+30 policy may be shrinking due to the changes in the past year). I'm only a single data point so the question is important to ask, how long are third parties, especially those using LLM's willing to wait to release their side? Equally worth asking is would any of them consider the public release of test as a permission to disclose their PoC's sooner and what impact that has.

IMHO: Tests withholding more just makes us feel more secure rather than making us truly more secure.

I think for core we should default to releasing the tests with the security release and only hold them back if we're specifically uncomfortable with them going out. But then if we really are uncomfortable two months seems OK.

For me the main issue is the overhead of removing the tests and opening an issue months later and then a separate review/RTBC/commit step for core all over again. And not being able to fully close the security issue for the two months until those additional steps are completed. Lack of tests also makes any public followup work on the issue harder to do. And people working on those public issues may not even know there are private tests that are embargoed.

+1 for catch's proposal in #5, less work for committers and security team members; I am sure we have some security issues where we forgot to add the tests or are languishing in the core queue.

I think my suggestion in #5 is pretty close to the current policy but without checking I think we've been tending towards embargoing tests recently in practice so it would be loosening how it's applied.

https://www.drupal.org/drupal-security-team/contacted-by-the-security-te... Still says If you have created automated tests that test the vulnerability do not commit them at the time of the release, but instead hold onto them for a while (e.g. 2 weeks) before committing

Back to needs work for the docs to be updated to match the core policy.

Actually I'll mark it as Fixed so that I can assign contribution credit.

Unless something has changed that I missed even non-fixed issues should receive credit. That changed about a year ago IIRC.