Security policy and CNA scope

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.