Skip to content
Gelhaus Solutions

CNA scope statement

The scope as submitted, what it covers for each product, and what has been asked for but not yet granted. The reporting process is on the policy page.

Issued by
Gelhaus Solutions · CNA scope statement
Programme
Application in progress
Jurisdiction
Germany
The other half
Disclosure policy →
Last changed
13 September 2026
01 · The statement

Applied for, not granted

Nothing here carries assignment authority yet.

This statement is the scope Gelhaus Solutions has applied for as a CVE Numbering Authority. The application has not been decided, so nothing on this page carries assignment authority yet, the products listed below included.

What is in effect today is the disclosure policy. A vulnerability in anything listed here is handled on the published timelines whether or not the application ever clears: it gets an advisory identifier under the GSSA- prefix, and anything warranting a CVE is routed through the relevant Root rather than held until the answer arrives.

Vulnerabilities in the products and services of Gelhaus Solutions that are not in the scope of another CNA. This includes the GHub product line and the tools published under the Gelhaus Solutions organisation.

For each product the scope covers its source repositories, the artifacts released or distributed from them, and the production deployments Gelhaus Solutions operates, whether or not the source is public at the time the vulnerability is reported.

Vulnerabilities in Postiz are not in this scope. Postiz is covered by its own CNA.

That is the statement in full. Everything below is the same thing said in more detail, and if the two ever disagree the statement above is the one that counts.

A product is not just its repository

Scope is stated per product and covers the whole of it: the source repository, whatever is released or distributed from it, and the deployment run by Gelhaus Solutions. A finding in a hosted instance is in scope on the same terms as one in the code, because to the person affected by it there is no difference.

Not all of the GHub repositories are public yet. That makes no difference to scope. A vulnerability in a product is the product's vulnerability whether or not you could read the source when you found it, and a report against a component that has not been published yet is handled on the same terms as any other. Publishing the repositories will add nothing to this page, which is the point.

Where one name covers more than one deployable thing (an app and a runner, a platform and the instance of it), the entry in the list says so rather than leaving it to be inferred.

Anything not listed

Reports about something not on this page still get read and still get an answer. If it turns out to be mine, it gets added here and handled under the policy. If it belongs to somebody else, it gets pointed at them.

Nothing is refused for being unlisted. The list states what is already known to be covered; it is not a filter on the inbox.

02 · Scope as submitted

15 products

8 of them have nothing released yet. They are listed because scope should exist before the first release rather than be added after it, and they are marked so nobody goes looking for something to test.

GAdvisory Full
A security advisory platform that isn't tied to one ecosystem's database.
GControl Full
A management broker that runs inside your own infrastructure.
GPlatform Partly Not released yet
Partially in scope, modules shipped by GPlatform are in scope, the actual platform is not, as it is not shipped to prosumers.
GOpenCSR Full Not released yet
One account, one log and one place to govern, for every G Open registry.
GOpenCDR Full Not released yet
Community top-level domains alongside the normal internet, signed from the root down.
GOpenCNR Full Not released yet
Your own addresses and ASN on a private network, routed through hubs and encrypted end to end.
GeGroups Full
Groups and mailing lists, built to be run.
GAnalytics Full Not released yet
Analytics where every dataset is a module.
DAnalytics Full Not released yet
Discord analytics, stored by shape.
GBoarse Full Not released yet
A stock market simulation.
Gates pull requests behind a contributor application, as a GitHub App or from inside GitHub Actions.
Vulnogram Partly
This is a fork of vulnogram/vulnogram, only vulnerabilities applying to our repository are in scope.
Gelhaus Solutions maintains this fork of Kener. Reports about code we wrote or changed belong here. Reports about upstream Kener code we have not modified belong to the upstream project. Upstream changes are merged selectively after review, so a report can reach us before the upstream fix is in our tree. Anything that lands with us first gets forwarded upstream, and we track the fix until we have merged it.
This is a fork of discord-tickets/bot, only vulnerabilities applying to our repository are in scope.
AetherNet Full Not released yet
A control plane for a fleet of autonomous agents that happen to live in Minecraft.
03 · Not in scope

2 exclusions

Excluded from the statement above, and listed rather than omitted, so the boundary against other CNAs and upstream projects can be checked rather than assumed.

Covered by the Postiz CNA, with MITRE as TL-Root, and by GCVE Numbering Authority 125. I run that programme, but it is a separate authority with a separate scope: report Postiz findings there rather than here. PSA-
Part of the Postiz platform and covered by the same CNA, despite living in its own repository. Same programme, same place to report. PSA-
04 · Asked for, not in the statement

Proposed, not in effect

These were asked for alongside the application and deliberately kept out of the submitted statement. The difference from the scope above is not that one is granted and the other is not: neither is. It is that the products above are what the application asks for, while these ask for authority over software somebody else publishes, which a statement cannot claim while nobody has granted it.

Findings in somebody else's software

Not in scope
Proposed wording. Not in effect.

Vulnerabilities in software published by a third party, where Gelhaus Solutions discovered the vulnerability itself or the finder asked Gelhaus Solutions to coordinate it, and where the affected product is not in the scope of another CNA.

Where it stands

Asked of MITRE as part of the CNA application, in the same request as the gadvisory.org clause. Awaiting a decision.

Why it was asked

The coordination already happens here. The reproduction, the contact with the vendor, the severity call and the disclosure date sit with whoever did the work, and today the identifier has to be requested from a CNA that has none of those things in front of it. The clause would put the number with the party doing the coordinating. It asks for nothing else over anyone else's product.

What happens today

The finding is handled either way, and the route is the same one it has always been. Gelhaus Solutions contacts the vendor, writes the advisory and publishes it on gadvisory.org under a Gelhaus Solutions advisory identifier. That part needs nobody's permission. The CVE is requested from the product's own CNA where it has one, and from the CNA of Last Resort where it has none, with Gelhaus Solutions named on the record as the reporter rather than the assigner. If you have found something in software that is not mine and want help getting it to the people who can fix it, that offer stands today and does not depend on this.

Even if granted

It is a clause about who assigns an identifier, and nothing more. The fix, the timeline and the decision to publish stay with the vendor whose software it is. The response times on the disclosure policy are commitments about products in the scope above, not about somebody else's code. And a product whose vendor runs its own CNA stays with that CNA no matter who found the bug.

Projects onboarded to gadvisory.org

Not in scope
Proposed wording. Not in effect.

Vulnerabilities in third-party projects onboarded to gadvisory.org whose maintainers request an identifier from Gelhaus Solutions, where the project is not in the scope of another CNA and its maintainers have asked for or agreed to the assignment.

Where it stands

Asked of MITRE as part of the CNA application. Awaiting a decision.

Why it was asked

GAdvisory already holds the whole record for these projects: the maintainers onboarded them, and the advisory is drafted, reviewed and published there. The identifier is the single part that has to come from somewhere else, which splits one advisory between two parties and leaves the maintainer chasing the half that is not here. The clause would close that gap, and only for maintainers who ask it to.

What happens today

Until there is an answer this is not in scope and is deliberately absent from the statement above. A third-party project onboarded to gadvisory.org can have its advisory hosted and published there today (that part needs nobody's permission), but the identifier still has to come from the project's own CNA, or from the CNA of last resort where it has none.

Even if granted

Onboarding a project would not put it in scope by itself: the maintainers have to ask, per project, and they can stop asking. Hosting an advisory on gadvisory.org transfers nothing and implies nothing: a project whose vendor runs its own CNA keeps it, and GPlatform Advisory customers are covered by this clause on exactly the same terms as anyone self-hosting, which is to say not yet.

05 · Programme identifiers

How this programme is named

The names and addresses the application is filed under. The CPE vendor name is not assigned while the application is open, so the row is absent rather than blank.

Organisation
Gelhaus Solutions
Jurisdiction
Germany
Status
Application in progress
Advisory prefix
GSSA-
Advisories
gadvisory.org
Reporting one of these

The channels, the response times and the safe harbour terms are on the policy page. This one only says what is covered.

Disclosure policy