Security policy and CNA scope
How to report a vulnerability in anything Gelhaus Solutions publishes or runs, what is covered, and what happens after you send it.
- Issued by
- Gelhaus Solutions · Vulnerability disclosure policy
- Programme
- Application in progress
- Jurisdiction
- Germany
- This document
- https://gplatform.org/security/policy
- The other half
- CNA scope statement →
- Last changed
- 13 September 2026
What this policy says
Scope
Gelhaus Solutions handles vulnerabilities in the software it publishes and the services it operates: the GHub product line and the tools published under the Gelhaus Solutions organisation.
For each product that means the whole of it: the source repository, the artifacts released from it, and the production deployment, whether or not the source is public at the time you report. The scope statement is the exact wording, and the list on it is authoritative.
The table below is that list, in full. It says what is covered, what is only partly covered, and what is not covered at all, because a reporter is owed the third of those as much as the first.
One boundary is worth stating plainly: Postiz is not in this scope. It has its own CVE Numbering Authority with MITRE as TL-Root, and its own GCVE Numbering Authority. Findings in Postiz go to that programme, and the Postiz page says how.
Reporting a vulnerability
Email egelhaus@ennogelhaus.de, or file it through GAdvisory. Both reach the same person and both start the same process.
Use GAdvisory when you want to follow the report through triage and read the draft record before it publishes. Use email when you would rather not create an account, or when the report needs encrypting. There is a PGP key for this domain published over WKD, with the fingerprint further down this page.
Please do not open a public issue and do not post it in a Discord channel. Neither is forbidden, but both are public the moment you press send, and that takes the timeline out of everyone's hands including yours.
What a useful report contains
What you did, what happened, and what you expected instead. A version or a commit. Enough detail to reproduce it.
If you have a CVSS vector in mind, send the vector rather than the number. The vector is the part worth arguing about, and that argument is better had before the record is written than after.
If you are not sure whether what you found is a vulnerability, send it and say so. Deciding that is my job, not a prerequisite for talking to me.
Assessment and disclosure
The timelines below are commitments, not aspirations. Where one is going to be missed you will be told before it is missed, with a reason and a new date.
Every record gets a CVSS vector with the reasoning written down, and a CWE chain rather than a single identifier, so the root cause ends up on record instead of only the symptom.
Safe harbour
Report in good faith and I will not pursue you for it, and will not ask anyone else to.
Good faith means testing only against your own installation or an account you control, not accessing or modifying anyone else's data, not degrading the service for other people, not running automated scanning that amounts to a denial of service, and giving the timeline below a chance to run before going public.
Stay inside that and finding a bug is a favour. Step outside it and it stops being a research question.
Credit
The default is that your report ends up on the public record with you credited by whatever name or handle you give me. Say the word and it will not be. Either way you get told before publication, not after.
What is not a vulnerability report
Automated scanner output with no analysis attached. Missing security headers with no exploit path described. Best-practice findings with no stated impact. Reports whose only content is an offer to sell me the details.
Anything genuinely out of scope still gets an answer saying so, and why. Silence is not one of the outcomes.
Response times
Every row is a commitment, not an aspiration. They apply to anything in the scope below, in either language, whether or not you are a customer.
Within 3 working days. A reporter waiting in silence cannot tell being triaged apart from being ignored, so this one comes first and comes fast.
Within 10 working days: whether it is accepted, the severity, the CVSS vector with its reasoning, and the CWE chain.
Set by severity and agreed with you when the assessment lands, rather than promised in advance of knowing what it is.
90 days from the report, or when a fix ships, whichever comes first.
By agreement, and stated publicly on the record when the advisory goes out. A deadline moved quietly is not a deadline.
You hear before it slips, with a reason and a new date, not afterwards.
What is covered
Grouped by who assigns the identifier. The first group is this programme; the rest are named so the boundary can be checked rather than assumed. Nothing is refused for being unlisted: an unlisted report still gets read, and gets an answer.
The commitments above are in effect today. The CNA scope they refer to is applied for and not yet granted, so what the application decides is who issues the identifier, not whether a report gets handled. The scope statement on its own →
Gelhaus Solutions
My own software: the GHub product line, the tools published under the Gelhaus Solutions organisation, and the hosted instances of them. This is the scope the CNA application covers.
A security advisory platform that isn't tied to one ecosystem's database.
A management broker that runs inside your own infrastructure.
Partially in scope, modules shipped by GPlatform are in scope, the actual platform is not, as it is not shipped to prosumers.
One account, one log and one place to govern, for every G Open registry.
Community top-level domains alongside the normal internet, signed from the root down.
Your own addresses and ASN on a private network, routed through hubs and encrypted end to end.
Groups and mailing lists, built to be run.
Analytics where every dataset is a module.
Discord analytics, stored by shape.
A stock market simulation.
Gates pull requests behind a contributor application, as a GitHub App or from inside GitHub Actions.
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.
A control plane for a fleet of autonomous agents that happen to live in Minecraft.
Covered by another CNA
Named here so the boundary is explicit. I run this programme too, and it is a separate authority with a separate scope.
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. Published advisories →
Part of the Postiz platform and covered by the same CNA, despite living in its own repository. Same programme, same place to report. Published advisories →
Reporting channels
Encrypted or not, either language, and no account anywhere. What a report should contain is in the policy above; none of it is a condition of being read.
Best for anything that needs a record. Security reports, scoping, work enquiries.
Identifiers and records
Who assigns the identifiers, what format the records come out in, and the key material to send something under.
- CNA status
- Application in progress. Until it is granted, findings get an advisory identifier under the GSSA- prefix, and anything warranting a CVE is routed through the relevant Root rather than waiting on the application.
- Record formats
- CVE Record Format 5.1 and OSV, with CVSS 3.1 and 4.0 vectors and CWE chains rather than a single identifier.
- Where records publish
- Through GAdvisory, at gadvisory.org. Advisories against GAdvisory itself publish there too, in the same format as any third-party report.
- Encryption key
- Published for this domain over WKD.
gpg --locate-keys contact@gplatform.orgfetches it. - Fingerprint
F066 2191 307B 7D43 84FE B7C1 1DE1 AF26 AD7E 24DF- Machine-readable
- /.well-known/security.txt, per RFC 9116.
- Languages
- English or German, whichever suits you. It makes no difference to the timeline.
Postiz has its own CVE Numbering Authority and its own scope. Reports for it go there, not through this policy.