Most projects do not need a pre-disclosure list. Consider one only if a small number of providers redistribute or host your code and need time to patch before the public hears about the issue. If you create one, keep it short, send the notice days before release, and include the CVE ID, affected versions and the date.
What the guidance says
The OpenSSF maintainer guide lists an embargo list as optional, useful when providers depend on the project, and says most projects do not need one. When one is used, the guide describes notices going out anywhere from 1 to 30 working days before disclosure, containing the CVE ID, a description, credit, affected versions, patch availability and the disclosure date.
Do you need one?
Ask:
- Do a handful of organisations package, host or ship your code to many others?
- Would a few days of head start meaningfully reduce harm?
- Can you trust the recipients to keep it private?
If the answer to the first is no, skip the list and use a normal coordinated release: private fix, advisory, CVE, publish. Most libraries land here.
The cost of a list
A list brings obligations:
- Someone must maintain it and verify members.
- Every extra recipient is a leak risk.
- You need written rules for membership and timing.
- You may face pressure to include more members over time.
For a one-person project, this is real work. Be honest about capacity.
If you create one
- Set membership rules. For example, organisations that redistribute or host the project, with a named security contact.
- Keep the list small. Fewer recipients, fewer leaks.
- Use a separate address. The guide advises keeping your team's coordination alias distinct from the intake alias.
- Fix the timing. Notices go out under embargo, shortly before the public release date.
- State the embargo terms in each notice, including the date and time it ends.
- Pick the release day with care. The guide prefers Monday through Wednesday and suggests avoiding widely observed holidays.
A notice template
Subject: Embargoed security notice for PROJECT, release on DATE
Affected: versions X to Y
Fixed in: version Z (patch attached or linked)
CVE: CVE-ID
Summary: one paragraph
Credit: reporter name, if agreed
Public release: DATE and TIME with timezone
Please keep this confidential until then.
Alternatives that need no list
- Publish clear advisories in a machine-readable format so downstream scanners pick them up fast.
- Offer a security announcement mailing list that everyone can join, with notices going out at disclosure.
- For larger ecosystems, see how a long-running list works in Linux distros embargo process.
Quick check
How early should the notice go out?
The OpenSSF guide describes 1 to 30 working days before disclosure. Choose the shortest period that lets recipients patch.
Does a pre-disclosure list guarantee secrecy?
No. Each added recipient raises leak risk, so keep it small and rule-based.
Sources
Last reviewed: 19 October 2026.
