Report security issues through GitHub Security Advisories instead of Jira

vmassol · October 9, 2026, 10:39am

Hi devs,

Edit (2026-10-13): this idea is now the plan B. The preferred option is to keep security issues in our tracker, with confidential work packages in OpenProject, and we’re asking the OpenProject team what that feature will cover and when. We’ll choose one or the other once they’ve answered, so that we don’t switch twice. Following the feedback, I’ve also fixed the statements on the reproduction steps and the report form, and removed the step about informing the sponsoring companies through the forum. See my reply for the details.

We’re preparing to leave jira.xwiki.org for OpenProject (op.xwiki.org); the proposal for the migration will be posted soon. Before that, we need to agree on a new place for security issues. Today they’re reported in Jira with the “Confidential” security level, and we already use GitHub Security Advisories (GHSA) drafts for the advisory text, the private fork, the CVE and the credits. OpenProject doesn’t support confidential work packages yet, and it’s unlikely to be available within the next 6 months, so we can’t simply move this part of the process to op.xwiki.org.

This is a brainstorming, not a vote: I’d like to gather your opinions first. The idea below is to make GHSA the place where security issues are reported and discussed. Since it doesn’t depend on the migration, it could be applied as soon as we agree on it.

The idea in short

Security issues are reported privately on GitHub (“Report a vulnerability” button on the repository’s Security tab), or by email to the security@xwiki.org mailing list for reporters without a GitHub account.
All confidential content (description, reproduction steps, discussion with the reporter, fix review) lives in the GHSA advisory and its temporary private fork.
For each accepted issue, a committer creates a public placeholder issue with a neutral title in the issue tracker (Jira until the XS projects move, then OpenProject). It carries what the tracker is good at: the issue key used in commit messages, the assignee, the priority and the Fix Versions used by the release process and the release notes.
Creating and updating the placeholder can be one command for the committer, through a Claude Code skill (see below).
When the advisory is published (3 months after the fix is released, as today), the placeholder issue gets the security label and a link to the advisory.
Reporting confidential issues in Jira stops. Open confidential Jira issues are handled as they are now until the XS migration, when each one gets a GHSA draft (most already have one) and a placeholder work package with the same key.

Why GHSA

Most security researchers already have a GitHub account. They don’t need to create an account on our tracker.
Reports are always private. Today a reporter can forget to set the “Confidential” level in Jira, which discloses the issue publicly.
One place for the whole lifecycle: the report, the discussion with the reporter, the fix in a private fork (the reporter can contribute to it), the CVSS score, the CVE request (GitHub is a CVE Numbering Authority), the credits and the publication. We already do most of this in GHSA, so this removes the back-and-forth between Jira and GitHub.
The discussion stays private after publication. Only the advisory description becomes public, while the comments and the edit history stay visible to collaborators only. Since the report form’s answers (including the reproduction steps) go into the description, the committer moves them to a comment at acceptance (see the committers’ steps). Today, removing the Confidential level in Jira makes every comment public.
A structured report form, defined once for all our repositories, asks reporters for what we need (affected version, steps, impact). Its answers become the advisory description, which is rewritten at acceptance.
It’s independent of the tracker migration, so it can be applied now and it doesn’t depend on OpenProject delivering confidential work packages.
It’s a common practice. Publishing advisories on GHSA is close to a standard (it feeds the GitHub Advisory Database, Dependabot and OSV), and more and more projects also take reports there. See the survey below.

What other projects do

I checked the security policies of about 30 well-known open source projects:

How reports are received	Projects
GHSA private reporting	CPython, Spring, Jetty, Mastodon, OpenProject (GHSA or email)
Private issues in the project’s own tracker	Jenkins (Jira), Mozilla (Bugzilla), Wikimedia (Phabricator), Moodle, GitLab (as a second option)
Bug bounty platform (HackerOne, Intigriti, YesWeHack)	Node.js, Rails, curl, Nextcloud, WordPress, Discourse, Kubernetes, GitLab, Grafana
Private email list	Apache projects (Tomcat, Log4j…), Django, Go, Rust, OpenSSL, Keycloak, Quarkus, Mattermost, Next.js, Vault, Matrix

Some takeaways:

There’s no single standard way to receive reports, but GHSA private reporting is growing among projects hosted on GitHub. Jetty, for example, does triage and discussion in the advisory comments and handles email reports by creating the advisory itself, which is what’s proposed here.
Projects that receive reports elsewhere still publish their advisories on GHSA (Keycloak, Rails, Grafana, Discourse, Nextcloud, WordPress, OpenProject).
The OpenSSF guide for maintainers accepts either a tracker with private issues or email for receiving reports. It recommends using the GHSA private fork to develop the fix, and keeping an email address as a fallback. That’s why the mailing list stays.

Details: the survey, project by project

Sources: each project’s SECURITY.md or security policy page, read on 2026-10-07, and the OpenSSF maintainer guide.

Project	Where reports go	Fallback	Tracking and publication
CPython	GHSA private reporting	—	GHSA
Spring (all projects)	GHSA, in one central repository (`spring-projects/security-advisories`), with a template and a sample pushed to the advisory’s private fork	—	GHSA, spring.io
Jetty	GHSA private reporting (“preferred”)	Email; the team creates the advisory for email reports	Triage in the advisory comments; CVE through a confidential Eclipse GitLab issue
Mastodon	GHSA or email (equal)	—	GHSA
OpenProject	Email or GHSA (“if you prefer”), not its own tracker	—	GHSA, release notes
Jenkins	Its own Jira, SECURITY project (visible to the reporter and the security team only), one component per core/plugin	Private mailing list (the team files the issue)	Jira, jenkins.io advisories
Mozilla	Its own Bugzilla, security bugs	security@	Bugzilla, advisories
MediaWiki / Wikimedia	Its own Phabricator, “Report Security Issue” form	Email (the team creates the task and adds the reporter)	The task is made public at fix time
Moodle	A security form linked to its own tracker	—	Tracker
GitLab	HackerOne	Confidential issue in its own GitLab (email no longer accepted)	Issues made public 90 days after the fix
Node.js, Rails, curl, Nextcloud, WordPress, Discourse	HackerOne	Email (some)	Own advisories; most also publish on GHSA
Grafana	Intigriti	Email	GHSA
Kubernetes	HackerOne	Email list	Own process
Keycloak	Email (plus a YesWeHack bounty)	—	GHSA
Apache (Tomcat, Log4j, all ASF projects)	Email, security@ or project lists	—	The ASF is the CNA; Jira after disclosure
Django, Go, Rust, OpenSSL, Quarkus, Mattermost, Next.js, Vault, Matrix	Email	—	Own advisories (several also on GHSA)
XWiki (today)	Our Jira, Confidential level and `security` label	security@xwiki.org	Jira and a GHSA draft, then a published GHSA

Patterns:

There are four families: bug bounty platforms (projects with a budget or a company behind them), private email lists (foundations: ASF, Django, Go, Rust, OpenSSL), private issues in the project’s own tracker (projects with a strong tracker culture, like ours) and GHSA private reporting (growing among projects hosted on GitHub).
GHSA as the publication channel is close to a de facto standard, even for projects that take reports elsewhere, because it feeds the GitHub Advisory Database, Dependabot and OSV. We already do this.
The closest project to ours is Jenkins: Java, self-hosted, a core plus about 2,000 plugin repositories on GitHub (like our core and contrib). It keeps reports in its own Jira. Spring solves GitHub’s “one form per repository” limitation with a single central advisories repository.
OpenProject itself takes reports through GHSA or email, not through confidential work packages.
Many policies now warn against unreviewed AI-generated reports (Keycloak, Go, curl). Open channels, GHSA private reporting included, receive the most of them.

Details: GHSA vs an issue tracker, need by need

supported · partial or workaround · missing. The tracker column is an issue tracker with confidential issues, like Jira as we use it today (OpenProject doesn’t have them yet).

For reporters

Need	GHSA	Tracker with confidential issues
Account needed	GitHub account (most researchers have one)	An account on our tracker
Single entry point	one form per repository: the reporter chooses platform, commons, rendering or a contrib repository	one site, pick the project
Wrong place	no transfer between repositories: close and recreate	move the issue
Structured form	customizable form, defined once for the organization, plus CVSS and CWE fields	free text; in Jira the reporter must also set the security level
Private by default	always	in Jira the reporter must pick “Confidential”, and forgetting it discloses the issue
Attachments (screenshots, proof of concept)	inline in the description and comments
Following the status	4 coarse states (triage, draft, published, closed)	workflow status, Fix Version, resolution
Discussion with the team	comments and GitHub notifications	comments and email notifications
Proposing a fix	temporary private fork	(goes through a GHSA fork anyway today)
Credit and CVE	native (GitHub is a CNA)
Reporting without an account	(security@xwiki.org stays the fallback)

For committers

Need	GHSA	Tracker with confidential issues
Assignee	only collaborators
Triage queue across all repositories	per repository in the UI; organization-wide through the API only	saved filters, dashboards
Full-text search in drafts	in the UI; through the API
Priority and CVSS	severity or CVSS vector	priority and CVSS fields
Labels and components	(CWE only)
Fix Versions tied to releases (release plans, release notes)	patched versions are free text
Issue key for commit messages	a GHSA id would itself reveal a security fix
Links, duplicates, blockers
Issue spanning several repositories	one advisory can list several packages, but it lives in one repository, and so does its private fork	one issue per project, plus links
Trusted non-committers (sponsoring companies)	the XWiki/Security team as collaborator, or the security manager role	security level group
Disclosure	publish the advisory (as today)	make the issue public, with all its comments
Embargo tracking and reminders	the Security Advisory Application imports GHSA	Same application
API and automation	REST API (create, update, CVE, fork)
Available now	(private reporting to enable)	Jira: yes, but it’s going away. OpenProject: not before 6 months

Conclusion: GHSA is excellent for the collaboration between the reporter and the people fixing the issue, and we already use it for that. It isn’t an issue tracker, though, so GHSA alone doesn’t work; that’s why the idea pairs it with a public placeholder issue, which covers every in the committers’ table.

Details: facts checked on our repositories (2026-10-07)

Private vulnerability reporting is currently disabled on xwiki-platform, xwiki-commons and xwiki-rendering. It can be enabled for a whole organization through a security configuration.
xwiki-platform already has 112 draft, 234 published and 4 closed advisories.
The xwiki organization has 10 public repositories and xwiki-contrib 370.
An advisory goes through these states: triage → draft → published, or closed. The API filters by state only.
An advisory holds: summary, description, severity or CVSS vector, CWE ids, affected packages with vulnerable and patched versions (free text), credits, collaborators (users and teams), CVE id.
The report form’s answers are merged into the advisory description, which is what gets published. Comments and the edit history stay visible to the advisory’s collaborators only, even after publication. Since 2026-10-02, comments can be listed, read, added and edited through the REST API (public preview), so tooling can copy the discussion elsewhere; maintainer-only confidential comments are only returned by the GraphQL API.

Limitations and how we handle them

GHSA isn’t an issue tracker: it has no assignee, components, versions, links or saved searches. → That’s the role of the placeholder issue.
Reports are per repository, so a reporter has to pick xwiki-platform, xwiki-commons, xwiki-rendering or a contrib repository. → The security policy says “if unsure, report on xwiki-platform”. A committer recreates the advisory in the right repository when needed, since an advisory can’t be moved.
A GitHub account is required. → The security@xwiki.org mailing list stays open to anyone.
Two items to keep consistent per issue (the advisory and the placeholder). → The advisory holds the placeholder key; the placeholder never links to the advisory before publication. The Claude Code skill below does both updates.
A placeholder with a neutral title is visible before disclosure. → Same rule as our obfuscated commit messages: the title describes the change, not the vulnerability.

Making the placeholder a one-step task

The extra work this adds for committers is the placeholder issue. We can make it simple with a Claude Code skill, run by the committer handling the security issue, for example with the advisory’s URL:

At acceptance: it reads the advisory, picks the tracker project from the repository, proposes a neutral title (which the committer validates), creates the placeholder with the assignee, the priority computed from the CVSS score and the Fix Versions, then writes the placeholder’s key into the advisory.
At publication: it adds the security label and the link to the advisory on the placeholder.

Committers who don’t use Claude Code can do the same by hand, following the steps below; it takes a couple of minutes.

The process, step by step

For reporters

Read the Security Policy (what counts as a vulnerability, how we compute severity).
Open the Security tab of the affected repository (xwiki-platform if unsure) and click Report a vulnerability. Without a GitHub account, send the same information by email to security@xwiki.org.
Fill in the form: affected versions, description, reproduction steps, impact.
Follow the discussion in the advisory comments (GitHub notifications), answer questions, and optionally contribute a fix in the temporary private fork.
Get credited in the advisory when it’s published, with a CVE.
Don’t disclose the issue until the advisory is published.

For committers

Receive the report: GitHub notifies the security team (it gets the security manager role on the xwiki and xwiki-contrib organizations). Email reports arrive on security@xwiki.org: the committer creates the advisory and adds the reporter as a collaborator if they have a GitHub account, otherwise relays by email.
Triage in the advisory comments: reproduce it, ask the reporter for missing information. If it’s not a vulnerability, close the advisory with an explanation. If it’s in the wrong repository, recreate it in the right one.
Accept (“Accept and open as draft”), add the XWiki/Security team as collaborator, compute the CVSS score following the Security Policy, and set the CWE and the affected versions. Move the reproduction steps and the proof of concept to a comment, and rewrite the description with our advisory template (Impact, Patches, Workarounds, References), since the description is what gets published.
Create the placeholder issue in the tracker, with the skill or by hand: neutral title (as for an obfuscated commit message), priority from the CVSS score, assignee, Fix Versions; no security label and no link to the advisory. Put its key in the advisory.
Fix it on all supported branches, in the advisory’s temporary private fork when working with the reporter or a non-committer (merged with the existing manual recipe, not from the GitHub UI). Commit messages use the placeholder key and stay obfuscated.
Release: the placeholder is closed with its Fix Versions, like any other issue. Refresh the advisory in the Security Advisory Application, which computes the embargo and sends the reminders.
Request the CVE (from GitHub, or from our own CNA once it’s in place) and publish the advisory at the end of the embargo (at least 3 months after the release, as today).
Update the placeholder issue (with the skill or by hand): add the security label and the link to the advisory, so that release notes and searches find it.

What it would imply

Enable GitHub private vulnerability reporting on all repositories of the xwiki and xwiki-contrib organizations, with one report form for all of them.
Give the XWiki/Security team the security manager role on both organizations, so it sees every report.
Write the Claude Code skill for the placeholder issue.
Update the Security Policy page and add a SECURITY.md to our repositories.
Remove the “Confidential” security level from new Jira issues once the existing ones are handled.

Questions for you

Do you see needs that GHSA plus a placeholder issue wouldn’t cover?
Would you prefer one central repository for all reports (as Spring does), instead of reporting on each repository?
Any concern about the neutral placeholder issue being public before disclosure?

If the feedback is positive, I’ll follow up with a proposal or a vote.

Thanks

MichaelHamann · October 9, 2026, 10:57am

From what I understand, everything that is collected in the structured report form becomes part of the advisory text body which is published, your two statements quoted above seem to suggest something else, though. Have you verified that the reproductions steps don’t become public by default?

We could manually move them to a comment and remove them from the advisory text (the history always stays private) but as far as I understand, by default everything from the initial form is published.

My impression from Managing security managers in your organization - GitHub Docs is that this grants way too much access, I would prefer trying a custom role that explicitly only grants read access to security advisory drafts and nothing else (like no permission to change any security settings of the organization).

What I like least about this approach is that it becomes impossible to effectively manage the security work. You can’t easily see anymore which high-severity issues don’t have an assignee yet, and there is no distinction in the list between a security advisory that has been finished and one that still needs to be fixed. That makes it easy to miss important issues. Now we already have our internal security advisory application into which we import draft security advisories, we could possibly implement a lightweight task management (add an assignee, and add one or two more states to better track the status) but it feels like inventing our own issue tracker. If we go this route, I would still suggest adding this kind of issue tracking to our security advisory application so we don’t lose track of security advisories.

As I fear we have no other choice, +0 from my side, but we’ll need to improve our security advisory application to not lose track of the security work.

mleduc · October 9, 2026, 12:17pm

While this is likely true, always sad to be strongly dependent of a proprietary service (through to be fair we are already tightly coupled to GitHub).

Note that we have ongoing work to stop using GitHub as a CNA (CVE Numbering Authority), and to use XWiki SAS (main sponsoring company) as a CNA. But I don’t think that’s an issue since GitHub allows providing a CVE emitted by another CNA.

Even if https://dev.xwiki.org/xwiki/bin/view/Community/SecurityPolicy/#HSecurityForum26Mailing-List says:

The forum channel must be used for warning the sponsoring companies that a new security issue has been discovered. It might be used for asking about a potential security issue.

I don’t think this is true in practice and the What’s the process to handle security issues? section has been updated recently and does not mention the forum anymore.
Afaik the Security section of the forum is only used for:

Discussing issues that cannot be done publicly without disclosing a security issue
Opening a vote to extend the embargo period of some security issues.

I’m +1 for a lack of a better idea in the context of wanting to quickly move to OP. Thanks

vmassol · October 13, 2026, 11:05am

Thanks @MichaelHamann and @mleduc for the feedback!

First, to clarify the goal: the preferred option is still to handle security issues in our own tracker, as today, using confidential work packages in OpenProject. We’re asking the OpenProject team what that feature will cover (for example, whether anyone can report an issue privately without being a project member) and when it will be available. This GHSA idea is the plan B: it’s there so that we’re ready, with an agreed process, if the answer isn’t good or if confidential work packages don’t arrive soon enough. Without it, security issues would block moving the XS projects off Jira, which is the reason for the migration.

You’re right, and my post was wrong on this point. GitHub added structured forms for private vulnerability reports recently (a VULNERABILITY_REPORT.yml file, defined once per organization), but the answers are merged into the advisory description, and that’s the text that gets published. Only the comments and the edit history stay private: after publication, anyone sees the current version of the advisory, and only collaborators see its conversation history.

So it needs an explicit step at acceptance: the committer moves the reproduction steps and the proof of concept to a comment, and rewrites the description using our usual advisory template (Impact, Patches, Workarounds, References). We already rewrite most descriptions into this template before publishing, so it’s mostly making the existing practice a rule. The placeholder skill can do it too (it proposes the new description, and the committer validates it). I’ll fix the two statements in the first post.

Agreed that the security manager role gives more than we need: read access to all repositories (they’re public anyway) but also the ability to change the security settings of the organization and of every repository. Unfortunately, custom organization roles and custom repository roles are only available on GitHub Enterprise Cloud, and the xwiki and xwiki-contrib organizations are on the free plan. The options I see:

Security manager role for the XWiki/Security team, accepting the extra rights. It’s the only role below owner and admin that gives access to all the advisories of a repository, including new reports in triage, and that gets notified of new reports. These members are already trusted with the undisclosed issues, which is more sensitive than the settings, and the organization audit log records any setting change.
No role: only organization owners and repository admins are notified of new reports, and they add the XWiki/Security team as collaborator on each one. It’s least privilege, but triage then depends on a few people.

I’d go with 1. WDYT?

+1, this is the biggest gap, and I’ll add it to the proposal as a prerequisite rather than a nice-to-have. To avoid inventing our own issue tracker, I’d keep the assignee and the status in one place, the placeholder issue, and have the Security Advisory Application join both sides:

Import the advisories in triage state too (new reports), not only the drafts.
Read the placeholder key from the advisory, and show the placeholder’s assignee, status and Fix Versions next to the advisory’s severity and embargo date.
Highlight what needs action: reports in triage for more than N days, accepted advisories without a placeholder or without an assignee (sorted by severity), and fixed issues waiting for publication.

The tracker then stays the place where work is assigned and scheduled, and the application gives the security-only view that the public tracker can’t give. If that’s not enough in practice, we can still add an assignee or extra states in the application itself.

Agreed. Two things limit it: the security@xwiki.org list stays open for anyone who doesn’t want to use GitHub, and the advisories themselves can be read and exported through the API. The one thing we can’t export is the comment threads (there’s no API for them), so they’d be lost if we ever left GitHub. Since we already rely on GitHub for the private forks and the published advisories, I think the extra dependency is acceptable.

Good to know, thanks. I’ll phrase it as “request the CVE (from GitHub, or from our own CNA once it’s in place)” so the process doesn’t depend on which CNA issues it.

Thanks, I’ll drop step 4. The Security Policy page still says the forum “must be used” to warn the sponsoring companies, so the rewrite of that page will fix this too, and describe the forum category as you did (discussions that can’t be public, and votes to extend an embargo).

Summary of the changes to the idea:

At acceptance, move the reproduction steps and proof of concept to a comment, and rewrite the description with the advisory template.
The XWiki/Security team gets the security manager role (or another option above, depending on your answers).
Tracking in the Security Advisory Application becomes a prerequisite: triage reports imported, the placeholder’s assignee and status shown, and the items needing action highlighted.
CVE from GitHub or from our own CNA.
No “inform the sponsoring companies through the forum” step, and the Security Policy is fixed accordingly.

Next steps: once OpenProject has answered, I’ll compare both options. If confidential work packages cover our needs and arrive in time for the XS move, I’ll propose them; otherwise I’ll propose this GHSA process with the changes above. Other feedback is welcome in the meantime, especially on what would make one option or the other a no-go for you.

Thanks

surli · October 13, 2026, 12:25pm

I think Michael and Manuel both summed up my feeling too: I’m really not super happy about doing that move, but I’d agree with it as a temporary measure as I don’t see a good solution except having proper support in OP. Improving the internal security advisory app for having a better view of what’s going on will probably help to not be lost in the multiple trackers.

For me a big question remains however regarding the transition: we currently have quite a lot of tickets in JIRA that are still confidential until the embargo is done. What do we plan to do for them?

MichaelHamann · October 13, 2026, 12:44pm

Wow, that seems like a big limitation to me. Reproduction steps and technical details of the vulnerability are important information that are used by several teams in XWiki SAS to understand, e.g., if an instance has been properly patched or if a certain configuration is affected. It is also important information to understand why exactly a certain change was done as neither the code nor the advisory contain the full details, and we need to be sure that when we touch some code again, we don’t undo the security fix. It feels quite bad to me to lock and potentially lose this information in GitHub forever.

Currently, we also publish this information when we publish the advisory by publishing the Jira issue. There is value in not publishing everything, but I think we should ensure that this a conscious step we want to do and not a side effect of the migration. What I would prefer personally is that we don’t keep those details private forever but publish them eventually, like a year later, e.g., by copying it into our issue tracker.

vmassol · October 13, 2026, 12:45pm

Good question, and it applies to some contrib projects too. They stay in Jira, handled as today, until their project moves. Then:

Preferred option: they’re imported as confidential work packages, with the same keys.
Plan B: each one gets a GHSA draft (if it doesn’t have one yet) and a public placeholder work package with the same key and a neutral title. The confidential content isn’t imported into OpenProject.

Contrib projects move first, possibly before we’ve chosen, so:

A contrib project with confidential issues still in Jira moves with the XS projects, and is handled like them.
For contrib projects that have already moved, new security reports go to security@xwiki.org and are handled in a GHSA draft on the project’s repository until we’ve chosen. The public work package is created when the fix is committed.

In all cases the import must not make anything confidential public; we’ll check it on a test import first. And after the last migration, Jira stays available to the security team (read-only, no longer public) for 3 months.

I’ll post the Jira to OpenProject migration plan very soon.

MichaelHamann · October 13, 2026, 12:48pm

Actually, this is not true anymore, GitHub has introduced an API for comments of repository security advisories this month, so exactly what we’re looking for: Repository security advisory comments API in public preview - GitHub Changelog

This also sparks some confidence that GitHub is aware of the importance of that data and hopefully won’t just decide to delete it.

vmassol · October 13, 2026, 12:56pm

Thanks @MichaelHamann, good catch: I was wrong, the comments API (public preview) lets us list, read, add and edit advisory comments, including on private reports. The only exception is the new maintainer-only confidential comments, which only the GraphQL API returns. I’ll fix the first post.

Agreed, it should be a conscious choice, not a side effect of the migration. With the API, plan B could do this:

Some time after the advisory is published (a year, as you suggest?), a script copies the advisory’s discussion (the reproduction steps and technical details) as a comment on the placeholder work package, so it ends up public in the tracker, as with Jira today.
Confidential comments are left out, since they’re meant to stay internal.
The Security Advisory Application shows which advisories are due for this, like the other items needing action.

For the preferred option, what happens to the comments when a confidential work package is made public is one of the questions we’re asking the OpenProject team.

vmassol · October 19, 2026, 8:36pm

OpenProject suggested another option while waiting for confidential work packages: track the security issues in a private OpenProject project, and make them public when we disclose them. I’ve checked how it would work, both in the OpenProject code and on op.xwiki.org. Here’s the result.

How it would work

Reports still come by email or GitHub private reporting. A private subproject can’t receive them, because the “Non-Member” role only applies to public projects, so self-registered users can’t create work packages there.
Each public project that gets security issues (XWiki Platform, Commons, Rendering, and contrib projects when needed) gets a private subproject. Its only member is a “Security” group, the equivalent of today’s Jira Confidential level.
A security issue is one work package in the private subproject. Commits use its key. At disclosure, i.e. when the advisory is published, it’s moved to the public project, with its history and comments, as when we make a Jira issue public today. The old key keeps working as an alias.
Fix Versions work before disclosure: the public project’s versions are shared with its subproject (descendants sharing), and they’re kept on the move.
The reporter can follow and comment on their own work package through work package sharing (Enterprise, which op.xwiki.org has), without seeing the other confidential issues. If they’d rather not create an account, the committer relays from email or GHSA.
Internal comments (also Enterprise, also available) stay private after the move. That’s where anything that must never be published goes.
GHSA keeps its current role: the advisory text, the CVE, the credits and the private fork.
Existing confidential Jira issues: the Jira importer always creates private projects and keeps the Jira keys. We would import, move the confidential issues to the private subproject (the list comes from Jira, since the importer ignores security levels), and only then make the project public.

Pros

It’s a real tracker: assignee, status, priority, Fix Versions and saved queries, across all private subprojects. This covers the tracking gap that plan B has to fill in the Security Advisory Application.
There’s no public placeholder to create and keep in sync.
Moving to native confidential work packages later should be simple: move the issues back to their project and mark them confidential, once the feature exists.

Cons

Before disclosure, commits carry the private project’s key prefix (e.g. XWIKISEC-12), so anyone reading the git log can tell which commits are security fixes. Today it’s an ordinary XWIKI- key that the public can’t open, which is a weaker hint.
The key changes at disclosure. The old one stays as an alias, but our tools (release notes, queries on xwiki.org) must follow it.
There’s one private subproject per project. Categories, types and custom fields aren’t inherited, so they’re copied at creation, and a category that has drifted gets cleared at the move and has to be fixed by hand. With our contrib projects, this could grow to a lot of private projects.
There are still several places per issue: GHSA (advisory, CVE, fork) and the private work package, and then the public project.
Making a project public before its confidential issues have been moved out discloses them, with no way back. The migration needs a strict checklist.

My take

It’s a valid option, and it’s better than plan B at tracking. But I don’t think it’s simpler overall: it adds OpenProject structure to maintain (especially for contrib) and a visible security prefix in commits. So I’d keep the GHSA plan B as the fallback, and I’ve documented this option as an alternative in the migration proposal, with a pointer from REQM25 on the OpenProject requirements page.

WDYT? Would anyone prefer this option over the GHSA plan B?

PS: This post was co-written with Claude Code, which also checked the OpenProject code and op.xwiki.org’s configuration.

surli · October 20, 2026, 7:20am

I think I do prefer this option.

I’m not sure we would need a subproject per project? It’s not entirely clear to me why we need a subproject and not a distinct private project btw? For XWiki Standard we could have a single subproject (if we really need a sub) IMO, probably under platform. For contrib it’s less obvious, mainly because we might not want to handle a single list of people accessing all security issues of all contrib projects, but that could be discussed.

Btw something important that was not discussed: does OP provide the capability to grant access to a private ticket for specific people (our “Special allowed user” field in jira)?

I agree that’s the most annoying part. We could decide that just for that we keep a placeholder ticket, something that could then be solved by. Having internal links in the same system simplifies it IMO.

Another solution would be to also use the same project for dev only tickets: we would use same project prefix but move immediately the ticket to make it public, keeping the prefix in the commit. That way we obfuscate a bit security fixes by having more commits with the same prefix than just security.

tmortagne · October 20, 2026, 7:39am

I think I’m not a huge fan of setting up a complex set of projects in OpenProject that will eventually be removed.

At least Plan B is not something that is far for the target setup (there will eventually be less in the advisory and more in the work package, but it will still be pretty much the same thing).

So my preference goes to Plan B for now. Well, my preference would go for waiting for OP to be ready, but it seems it’s not an option.

vmassol · October 20, 2026, 8:30am

My preference also goes with GHSA plan B:

GHSA reporting
Non-confidential OP issues with security-neutral titles and commits

This should allow us to migrate most contrib projects already. By that time, maybe OP will have progressed on the feature.

Thx