On 04/06/2026 18.50, Daniel P. Berrangé wrote:
It is no longer viable to handle the incredible volumes of
AI assisted security disclosures via email, nor are extended
embargos practical or useful.
Remove all information about the current security process and
instruct reporters to use 'confidential' issues. In contrast
to the old highly restrictive "need to know" approach, the
new approach makes all security issues visible to all QEMU
maintainers immediately.
Slightly off-topic question ... but: Should we require all maintainers to
have a gitlab account now? Otherwise we might end up with confidential
issues nobody is looking at since the related maintainer does not have a
gitlab account and the other maintainers don't care?
...
+## How to disclosure a potential issues
+
+**The QEMU project no longer accepts security issue disclosures via email.**
+
+New disclosures must follow the [report a bug](report-a-bug.html)
+process to file a GitLab work item for each potential issue, ***marking
+it as "*confidential*" prior to submission.***
+
+If unsure of the security implications of an issue, err on the side
+of caution and mark it as "*confidential*" initially.
+
+## Handling of disclosures
+
+Disclosures made via "*confidential*" GitLab issues are visible to, and
+may be handled by, any QEMU subsystem maintainer whom has a GitLab
I am not a native speaker, but my (likely wrong) gut feeling say it should
be "who" instead of "whom" here?
+account [associated with the Reporter role in the
project](https://gitlab.com/qemu-project/qemu/-/project_members).
+Triage may also be performed by one or more automated tools and/or
+AI agents run by the project that have been granted access to the
+issue tracker.
+
+The first task upon receiving a disclosure is to evaluate eligibility
+to follow the security triage process.
+
+* Disclosures affecting code / features evaluated to fall under the
+[non-virtualization use case](
+https://www.qemu.org/docs/master/system/security.html#non-virtualization-use-case),
+will generally not be eligible for handling as a security flaw.
+Such disclosures should be immediately switched to the public
+bug report process by removing the "*confidential*" marker.
+
+* Disclosures affecting code / features evaluated to fall under the
+[virtualization use case](
+https://www.qemu.org/docs/master/system/security.html#virtualization-use-case),
+will be handled under a lightweight security triage process which
+emphasizes getting a fix merged to the latest development branch
+as quickly as possible.
+
+Any disclosure which gets switched to the public bug report process
+will be fixed at the discretion of the maintainer, if and when time
+allows.
+
+In all cases reporters are encouraged to develop and propose patches
+for issues themselves at time of disclosure, to speed resolution.
+
+**NOTE:** The QEMU project policy is that all security disclosures received
+using GitLab "*confidential*" issues **will eventually be made public**. Any
+information that the reporter considers to be be sensitive / private **must**
+be scrubbed before disclosure.
+
+## Triage process
+
+ * A maintainer will evaluate the circumstances of the issue
+ to determine if it can be misused for malicious purposes.
+
+ * If there is no potential for meaningful exploit, the disclosure
+ should be switched to the public bug report process by removing
+ the "*confidential*" marker.
+
+ * If confirmed as a security flaw, a maintainer will request
+ add the **"cve::required"** GitLab label to the GitLab work item,
+ which indicates the need for a CNA to allocate a CVE.
+
+ * The maintainer(s) will develop and/or review patch(es)
+ for the issue privately, optionally attaching work in
+ progress fixes to the GitLab issues. All patches must
+ include the issue URL in the commit message(s).
+
+ * When a CVE is allocated, it will be recorded as a comment on
+ the GitLab issue, and the **"cve::requested"** label replaced by
+ the **"cve::assigned"** label.
+
+ * The maintainer(s) will update the commit message(s) to include
+ the assigned CVE. If multiple commits are required to fix an
+ issue the CVE must be included in the final commit in the
+ series, and may optionally be included in all prior commits.
+
+ * When the maintainer(s) are satisfied that the patch(es) are
+ suitable to propose for merge, they must be submitted to
+ the qemu-devel mailing list, and follow the normal process
+ for merge henceforth.
+
+ * At the time the proposed patches are sent to qemu-devel, the
+ maintainers should remove the "*confidential*" marker from the
+ GitLab issue.
+
+ * When the patch is merged into the current development
+ branch the issue must be closed. This should usually happen
+ automatically if the git commits referenced the GitLab issue
+ URL in [the normal
format](https://docs.gitlab.com/user/project/issues/managing_issues/#default-closing-pattern).
+
+The QEMU project currently co-ordinates with Red Hat for CVE
+assignment, in its role as the [CNA of last resort for OSS projects](
+https://www.cve.org/PartnerInformation/ListofPartners/partner/redhat).
+
+## Embargo policy
+
+The QEMU project policy is to limit the time that a disclosure has the
+"*confidential*" marker applied strictly to the minimum required to develop
+and publish a suitable patch and allocate a CVE.
+
+Given the widespread use of AI/LLM based agents for security auditing,
+as well as ongoing use of traditional fuzzing and static analyis
s/analyis/analysis/
+tools, the QEMU maintainers consider that any disclosure originating
+from automated tools is highly likely to be independently re-discovered,
+potentially many times over in a very short timeframe.
+
+Thus the QEMU maintainers will generally reject requests for arbitrary
+embargos unless high severity, extenuating circumstances can be
s/embargos/embargoes/
+demonstrated.
+
+If a patch for a confirmed security issue cannot be developed by a
+maintainer in a reasonable time, the maintainers may choose to make
+a disclosure public without having a patch available. This approach
+should only be taken for issues judged to have low severity.
Thomas
