Vulnerability Management

How GL finds, prioritises, and fixes security vulnerabilities, in its own code and in the third-party components it depends on. ← Back to G-Layer

Last reviewed: 17 August 2026

Detection

An automated dependency audit is run against GL's real dependency list at least monthly, independent of the deploy schedule, and again before any deploy that changes GL's dependencies.
Provider and platform advisories (Cloudflare, Anthropic, OpenAI) are reviewed when GL's use of those platforms could plausibly be affected.
Any vulnerability reported directly by a client or user is treated as detected the moment it is received.

There is no automated, continuous scanning pipeline today; scans are run manually on the cadence above. This is disclosed honestly rather than implied to be automated.

Real baseline, run 17 August 2026:

Severity	Count
Critical	0
High	4
Moderate	0
Low	0

All 4 High findings trace back to a development-time deployment tool GL uses to ship code, not to any package that runs in the live product. None of GL's actual runtime dependencies had a reported vulnerability at any severity in this scan. A fix is available for all 4 findings. This is a point-in-time result, not a standing guarantee; the next scheduled or pre-deploy scan may find a different picture.

Severity and response

Severity	Definition	Response target
Critical	Known to be actively exploited, or a trivially exploitable path to data exposure in a component GL actually uses at runtime	Same day, outside the normal deploy cadence
High	A real vulnerability with a plausible path to impact in a component GL uses	Within 5 business days
Moderate	Real but low likelihood of practical impact given how GL actually uses the affected component	Within the next 2 scheduled maintenance windows
Low	Minimal practical impact	Addressed opportunistically, no fixed deadline

Any Critical finding, or any finding that turns out to already be exploited, is escalated directly into GL's incident response process rather than handled purely as routine maintenance.

Prioritisation

Findings are prioritised using industry-recognised, CVSS-aligned severities from GL's dependency-scanning tooling, adjusted for judgement about whether GL's own usage of the affected component actually exposes the vulnerable code path, as with the development-tooling findings above, which do not affect the deployed product.

Tracking and notification

Findings and their remediation are recorded in GL's internal, dated change history, so there is one durable record rather than a separate tracker that can go stale. Where a finding is judged Critical or High and plausibly affects a specific client's data or availability, that client is notified directly, following the same approach described in GL's incident response process.

Review

This process, including the severity and response table above, is reviewed at least annually, and immediately after any incident that reveals a gap in it.

Reporting a security issue

If you believe you've found a vulnerability in GL, please report it via the contact in /.well-known/security.txt rather than a public channel, so it can be addressed before disclosure.