Temporary Closure of Vulnerability Intake Windows
(Potential annex or extension to GCVE-BCP-02 - Practical Guide to Vulnerability Handling and Disclosure)
Open source maintainers MAY temporarily close or suspend vulnerability intake windows for a defined period. This can be appropriate when maintainers are unavailable, on leave, recovering from burnout, observing holidays, or deliberately taking rest.
Such a closure is not a rejection of coordinated vulnerability disclosure. It is a sustainability mechanism intended to protect maintainer well-being and preserve the long-term viability of the project.
Principle
A temporary closure of vulnerability intake SHOULD be:
- announced clearly;
- limited to a defined period;
- documented in a visible place;
- accompanied by clear reporter expectations;
- accompanied by an emergency path for credible urgent cases, when possible.
Projects SHOULD avoid open-ended or undefined closures such as “security reports are closed until further notice”, unless the project is effectively unmaintained and this status is explicitly stated.
Example Policy
## Temporary Vulnerability Intake Pause
The vulnerability disclosure intake window for this project is temporarily closed from 1 August 2026 to 31 August 2026.
During this period, maintainers are unavailable and will not regularly review new vulnerability reports.
Reports submitted during this period will be queued and reviewed after the intake window reopens. We expect to resume vulnerability triage on 1 September 2026.
If you believe the issue is urgent, actively exploited, or creates immediate risk to users, please mark the report as `URGENT` and include concrete supporting evidence. Urgent reports may be reviewed earlier if a maintainer or trusted coordinator is available.
Please do not expect acknowledgement or triage during the closure period unless the report meets the urgent handling criteria.
Recommended Use Cases
Temporary closure of vulnerability intake windows MAY be used for:
- maintainer holidays;
- planned project downtime;
- personal leave;
- recovery periods after major releases;
- recovery periods after high-intensity incident handling;
- periods where no qualified maintainer is available;
- explicit project pauses;
- end-of-year or seasonal breaks.
Minimum Information to Publish
When closing an intake window, the project SHOULD publish:
Intake status: closed
Closure start date: YYYY-MM-DD
Closure end date: YYYY-MM-DD
Expected reopening date: YYYY-MM-DD
Reports during closure: queued for later review
Urgent exception path: available / unavailable
Alternative coordinator: optional
Example:
Security intake status: temporarily closed
Closed from: 2026-08-01
Reopens on: 2026-09-01
Reports received during this period will be queued.
Urgent reports should be marked `URGENT` with supporting evidence.
Emergency Exception
If possible, projects SHOULD define an emergency exception for severe cases.
A report MAY qualify for emergency handling when there is credible evidence of:
- active exploitation;
- compromise of project infrastructure;
- compromise of release artifacts;
- compromise of signing keys;
- unauthenticated remote code execution in widely deployed software;
- significant impact on downstream users or ecosystems.
However, small or volunteer-maintained projects MAY state that no emergency coverage is available during the closure period. This is preferable to creating false expectations.
Example:
No emergency coverage is guaranteed during this closure period. If the issue is already being exploited or affects a wider ecosystem, reporters may contact an appropriate coordinator, downstream vendor, distribution security team, or relevant GNA.
Interaction With Coordinators and GNAs
When a project is temporarily unavailable, reporters MAY seek assistance from a trusted coordinator, distribution security team, CERT/CSIRT, or relevant GNA.
The role of the coordinator SHOULD be to support responsible handling, not to pressure maintainers into interrupting legitimate rest periods except in genuinely urgent cases.
Where possible, the project MAY designate an alternative contact for the closure period.
Example:
During this intake pause, urgent coordination requests may be sent to security-coordinator@example.org. This contact is intended only for severe or actively exploited vulnerabilities.
Avoiding Misuse
Temporary closure SHOULD NOT be used to indefinitely avoid vulnerability handling.
A project SHOULD reconsider its process if:
- closures are frequent and unpredictable;
- no reopening date is provided;
- reports are silently discarded;
- urgent reports have no documented path;
- the project continues normal feature development while refusing all security intake;
- users are not informed that vulnerability handling capacity is unavailable.
If a project can no longer handle vulnerability reports at all, it SHOULD clearly document its maintenance status.
Best Current Practice
Open source projects SHOULD be allowed to define rest periods and temporary vulnerability intake closures. A sustainable disclosure process must recognize that maintainers are people, not permanent security response services.
A clearly documented temporary closure is preferable to silent non-response. It helps reporters understand when to expect a reply, reduces unnecessary follow-up pressure, and supports long-term maintainer health.