GAdvisory privacy notice
What a GAdvisory instance stores, why, and for how long. Written from the database schema rather than from a template.
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 kept alongside the parsed version for 12 months. That is deliberate: a report that was parsed wrongly is a report that has to be re-read as it was sent. After 12 months, an email's full header set, the IP address a web form was sent from and a webhook's body are deleted; the parsed report, its sender and recipients and its correspondence stay as part of the record. The original email is deleted from our intake mailbox 12 months after it arrived.
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. After 180 days the IP address and user agent are replaced by a keyed hash, which can still show that two entries came from the same place but cannot be turned back into them. 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 kept for 12 months so a proposal can be audited, then deleted; the record that the run took place, which tools it called and how many tokens it used stays.
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; their IP address and user agent are replaced by a keyed hash after 180 days.
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. In the browser, every visit is recorded as a replay and sent to Sentry, from the first page to the last: what was on screen, the clicks and what changed. It is not masked: it shows the page as it was on screen, including draft advisory text and what a reporter typed, because a masked replay cannot show what went wrong. To join the pages of one visit, the Sentry script keeps a random identifier in your browser's session storage, which is gone when you close the tab. IP addresses and request bodies are not sent. We do not ask for your consent to this recording or to that identifier. Recording every visit is how we find and fix what goes wrong in the service you are using, which we treat as part of providing it (Section 25(2) No. 2 TDDDG), and the recording rests on our legitimate interest in a service that works and is secure (Art. 6(1)(f) GDPR). You may object at any time (Art. 21 GDPR). If you block requests to Sentry in your browser, nothing is recorded, and the service keeps working. 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. You can download everything held about your account as a JSON file yourself, with "Download my data" in your account settings.
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.