GAdvisory privacy notice

Who is responsible

For gadvisory.org and for hosted GPlatform Advisory instances, the controller is Gelhaus Solutions, Eichenwald 3, 49624 Löningen, Germany. Contact: egelhaus@ennogelhaus.de.

For an instance you run yourself, you are the controller and we process nothing. Nothing in this notice applies to your installation except as a description of what the software is capable of storing, which you may find useful when writing your own.

What is stored, precisely

This is taken from the database schema rather than described in general terms, because a privacy notice that says "we may collect certain information" tells you nothing.

Your account. Email address, handle, display name, locale, timezone, country code, an optional avatar and biography, optional Git username and email for record signing, when your email was verified, and when you last signed in.

Disclosure requests. When somebody reports a vulnerability: the subject and body, the answers to whatever form was used, any file attachments, and either a linked account or a submitter name and email address. Where a report arrives by email, the message headers are kept with it — sender, recipients, any addresses in copy, and the message identifiers that thread a conversation — because a disclosure is a correspondence and the thread is the record.

The raw inbound payload is retained alongside the parsed version. That is deliberate: a report that was parsed wrongly is a report that has to be re-read as it was sent.

Participants in a request. Email address and display name for everyone on a thread, whether or not they hold an account.

Credits. Where a researcher is credited on an advisory, the name and contact they asked to be credited with. This is published, permanently, and that is the point of it.

Subscriptions. An email address, and nothing else. Subscriptions are confirmed by double opt-in and carry an unsubscribe token, so an address is only on a list because somebody clicked a link to put it there.

Browser push. Where enabled: the push endpoint your browser issues, its two keys, and the user agent string.

The audit log. Who did what, when, with the values before and after, plus IP address and user agent. Each row carries a hash of the one before it, so the log can be shown not to have been edited after the fact. That is a security property, and it means audit entries are not deletable in the ordinary way.

Share links. Where a link is created for someone outside the instance: the invited email address, and a hash of any PIN. Each use records a hashed IP address and the user agent — hashed, not stored, because the question a share link needs to answer is "was this used from more than one place", not "where is this person".

Attachments. Filename, content type, size, a SHA-256 digest, and the result of a malware scan. Files are held in object storage.

Credentials. API tokens, OAuth client secrets and application secrets are stored only as hashes. Integration secrets are envelope-encrypted, and an instance can be configured to keep them in HashiCorp Vault instead.

Artificial intelligence

The AI features are off unless somebody turns them on, are configured per scope, and run against an API key the operator supplies. GAdvisory ships no model provider of its own and sends nothing anywhere by default.

When they are on, they can draft and review advisories and triage incoming requests — which means the content of a disclosure report, including whatever personal information the reporter put in it, can be sent to whichever provider that key belongs to. Each stored credential records whether that provider trains on the data submitted to it, and the interface shows it.

The prompts and responses of each run are retained so a proposal can be audited, and are pruned on a schedule.

On gadvisory.org and the hosted service these features are enabled. They are restricted, but not in the way the word usually implies: the restriction is on who may run them — the Gelhaus Solutions team — and not on what they may read.

Within the scopes Gelhaus Solutions and Postiz own, that reaches disclosure reports, the request queues and disputes; for an administrator it is effectively the whole instance.

So: if you send a disclosure report to a Gelhaus Solutions or Postiz scope, its content can be sent to the model provider when somebody on the team runs a task over it. The provider is OpenRouter (OpenRouter, Inc., United States), which routes to Google Gemini. Scopes belonging to other organisations are configured by those organisations, not by us.

This is worth knowing before you write a report, which is why it is here rather than in a settings screen.

Why, and on what basis

Operating the service, authenticating you and keeping your account is performance of a contract, Art. 6(1)(b) GDPR.

Receiving, triaging and coordinating vulnerability reports is a legitimate interest under Art. 6(1)(f): the interest is in vulnerabilities reaching the people who can fix them. Where you send us a report, it is also Art. 6(1)(b), because you asked us to act on it.

The audit log, the abuse controls and the security of the service are Art. 6(1)(f).

Crediting a researcher by name is consent, Art. 6(1)(a), asked for at the time and withdrawable — although see the next section about what withdrawal can and cannot undo.

Subscriptions are consent, Art. 6(1)(a), and the double opt-in is the record of it.

Publication is permanent, and that is a limit on erasure

A published advisory is a public record. It is mirrored, indexed, aggregated into other vulnerability databases, and cited by systems we have no relationship with. We can remove a credit from our copy, and we will on request; we cannot remove it from everyone else's.

That is not a refusal of Art. 17. It is the honest scope of what erasure here can achieve, and it is worth understanding before asking to be credited by name.

How long

Account data is kept until the account is deleted. Deactivating an account marks it rather than erasing it; ask, and it is erased.

Disclosure requests and their correspondence are kept for as long as the coordination is open and afterwards as part of the record of how it was handled.

Audit entries are retained for the integrity of the chain.

Subscription addresses are removed on unsubscribe.

Published advisories, and any credit in them, are permanent.

Who else touches it

Hosting is on infrastructure operated by Gelhaus Solutions, on servers rented from IONOS SE (Germany) and, during a migration currently under way, Contabo GmbH (Germany), and on our own hardware in Germany. Mail runs on our own servers at IONOS, and file storage is our own MinIO on our own hardware. The rule we work to is that anything which can reasonably be self-hosted is, and almost all of this is.

Error and performance reporting goes to Sentry (Functional Software, Inc.), on its EU data region, so what it holds is stored in the EU. What reaches it is diagnostic — the exception and its stack trace, the request that failed, and the identifier of the signed-in user where there was one — and it is the only sub-processor here that is not simply a place the servers stand.

Browser push, where you switch it on, is delivered by the push service your own browser nominates: Google for Chrome, Mozilla for Firefox, Apple for Safari. Those are outside the EU, and there is no way to deliver a web push without one. The service receives the endpoint and the timing; the payload is encrypted to your browser's own keys, so it does not receive the content. Not enabling push means none of this happens to you.

Where an instance has AI features enabled, the provider whose key is configured receives whatever those features send it. That provider is chosen by the operator, not by us.

Publishing sends an advisory outward, on purpose. Publishing to GitHub Security Advisories sends the advisory and any credit in it to GitHub, Inc. in the United States — per advisory, and with the consent for it recorded against that advisory. Publishing through the CVE Program sends it to the CVE Program, also in the United States. So does syncing records into a Git repository you have configured.

Those are recipients rather than sub-processors: they receive a published document because publishing it was the whole point, and they then act for themselves rather than on our instructions. This is the machinery behind the section above about publication being permanent, and it is worth reading before asking to be credited by name.

No analytics service, no advertising network, and no third-party fonts or scripts are used.

Your rights

Access (Art. 15), rectification (Art. 16), erasure (Art. 17), restriction (Art. 18), portability (Art. 20), and objection to processing based on legitimate interests (Art. 21). Consent, where it is the basis, can be withdrawn at any time without affecting what was lawful before.

An informal email to the address at the top is enough.

You may also complain to a supervisory authority. The competent one here is Die Landesbeauftragte für den Datenschutz Niedersachsen, Prinzenstraße 5, 30159 Hannover.