Air-gapped and regulated environments
GAdvisory runs with no route to the internet at all. Not degraded, not read-only, and not with a queue of things waiting to sync: the entire workflow from report to published advisory completes inside your perimeter.
What works with the network switched off
Everything that is about your own vulnerabilities. Reports arrive, advisories are drafted, reviewed, given an internal identifier and published; they are searchable, they have public pages on your own hostname, they appear in feeds, and they mirror into your own git. Access control, audit and notifications all work.
What obviously does not work is anything whose whole purpose is to reach somebody else: assigning a CVE through a registry, mirroring an advisory to GitHub, or participating in the GAVR network. Those are features you configure, not dependencies you inherit, so an instance that never configures them never calls out.
This is a consequence of the architecture rather than a mode you switch on. There is no license check, no telemetry requirement and no phone-home. An instance that cannot resolve any external name is a fully working instance.
The environments this is for
Defence and government suppliers, industrial and medical device manufacturers, and anybody shipping into a customer's isolated network. In all of those, the vulnerability record is itself sensitive: what you are still fixing, and who told you about it, is not something to hold on infrastructure you do not control.
The same applies well before a formal air gap. An embargoed advisory naming an unpatched flaw in a shipped product is exactly the document you would not want in somebody else's database, whatever their terms of service say.
What an auditor will ask for
GAdvisory does not make anybody compliant with anything, and no product does. What it provides is the evidence a disclosure process is normally asked to produce.
| Question | What the product holds |
|---|---|
| Who changed this record, and when | An append-only audit log with a hash chain over its own rows, mirrorable into a git history you hold separately. |
| Who could see it before it was public | Per-level memberships with explicit roles, and a visibility on every scope and every advisory. |
| How disclosure timing was controlled | An embargo date on the record, enforced on every read path rather than by remembering not to publish. |
| How reports were received and answered | The whole thread on the request, including replies, refusals, and internal notes kept apart from what the reporter sees. |
| Where the data is and who processes it | Your database, your object store, your host. There is no third party in the path unless you configure one. |
Reporting obligations
Regulation increasingly requires manufacturers to report actively exploited vulnerabilities to a designated authority within a fixed window, and to keep a record of how each one was handled. GAdvisory holds the record and the timeline, and can publish to a numbering authority you operate yourself.
It does not file anything on your behalf and does not claim to satisfy an obligation, because whether a given process satisfies a given regulator is not a question a vendor gets to answer. What it does is make the record you would be asked for exist, in one place, with its history intact.
Related
How the product handles identifiers is the other half of this, since operating your own numbering authority is what keeps identifier assignment inside your perimeter too.