/// Security

What L3git does with your data: nothing.

L3git is a desktop application, not a hosted service. The short version is that your tests, the systems they exercise, and the credentials they use never reach us. This page states what we can show you how to verify, and says plainly where something is a business commitment rather than a technical guarantee.

Data handling

Your tests, the systems they exercise, your credentials, and the code L3git generates stay on your machine. We never receive them. There is no test-results cloud, no hosted execution grid you are required to use, and no account needed to run the product.

Everywhere the application can make a network call

For completeness, rather than a reassuring summary — the full outbound list:

Our licence endpoint — detailed in the next section.
Our update check — whether a newer version exists.
Your AI provider — only if you switch on the optional AI authoring features, and only using an API key you supply. Prompts go directly to that provider, never through us. If you do not enable AI features, this call never happens.
Browser-driver downloads — the Chrome and Firefox WebDriver binaries, from their official public sources, when a driver is needed.

On an offline key, every one of these is suppressed — including the update check.

Verify it yourself Run the app with a network monitor attached, or on a machine with no route to the internet, and compare what you see against the list above.

Licensing and activation

Licence enforcement is the only thing the application talks to us about, so here is exactly what it sends, how often, and what it keeps.

What is transmitted

Over TLS to our licence endpoint, the client sends: the licence key, a client-generated instance ID (a random GUID, not derived from your hardware), a truncated machine fingerprint (the first 12 characters of a SHA-256 hash — one-way and not reversible to anything about the machine), and the machine hostname. That is the complete list.

The client does not transmit an IP address. It also never sends your tests, the systems they exercise, your credentials, or any generated code — none of that is part of any licensing payload.

How often

A standard online key re-validates once each time the application starts — not once at purchase. Floating seats additionally heartbeat about every five minutes to hold the lease. If our server is unreachable, the application continues to work for a 14-day grace period and then warns rather than locking you out.

Keys issued with the offline flag make no outbound calls at all — activation, heartbeat, and the update check are all suppressed. See regulated & air-gapped.

What is stored on your machine

Beside the executable, the app keeps a hash of the licence key, the full machine fingerprint hash (only 12 characters of which are ever transmitted), the instance ID, and activation timestamps. Your licence key file itself is stored in cleartext, as with most desktop software — treat it with the same care as any other credential on that machine. These files persist until you deactivate or uninstall.

Verify it yourself Put the application behind a proxy or packet capture and watch the traffic: one short call at startup on a standard key, nothing at all on an offline key.

OWNER: the above covers what the client sends and keeps, which is all the client source can prove. Still needed before publishing: server-side retention — how long activation records are kept, whether the source IP (observable at the server even though the client never sends one) and the hostname are stored, and whether deactivate deletes the record or only frees the seat. The licensing server is being rewritten; these are decisions to make there, then state here.

What runs on the machine

The desktop app runs on the PowerShell that already ships with Windows — no Python, Node, or additional runtime is installed. The installer is digitally signed. Running the tests it generates needs JDK 17 or later and Maven, like any Java project.

Dependencies and supply chain

Generated projects are standard Maven, so every dependency is declared in a pom.xml you control and can scan with your existing tooling.

An opt-in checkbox adds a Maven Enforcer rule to the generated build that bans log4j: if it ever enters the dependency tree, the build fails loudly rather than shipping quietly. Because the rule lives in the pom.xml you own, your team can confirm it is present and enforced.

Verify it yourself Open the generated pom.xml, read the maven-enforcer-plugin configuration, and try adding a log4j dependency — the build should refuse it.

OWNER: state the policy for updating bundled dependencies (e.g. axe-core, the generated project's libraries) after a CVE is disclosed. The log4j ban above covers one named risk; a reviewer will also ask how the general case is handled.

Verifying our claims

Everything above is checkable without taking our word for it: the generated project is ordinary Java you can read, the dependency list is a file you own, and the application's network behaviour can be observed directly. If a claim on this page cannot be verified, we would rather hear about it.

Reporting a vulnerability

OWNER: supply a monitored disclosure address and a response commitment (e.g. acknowledge within N business days). A security page without a disclosure path is a red flag to exactly the buyer this page is written for. The generic company address is fine if it is genuinely monitored — but say which it is rather than leaving this to chance.

Certifications

L3git Development holds no security certifications — not SOC 2, not FedRAMP, not HIPAA, and nothing else. We are not going to imply otherwise, and you should be wary of vendors who do.

Where a compliance programme requires evidence, the architecture is the argument: the product does not receive your data, so a large part of the questionnaire is answered by what it never does. We also make no formal support commitment for STIG-hardened or FIPS-mode hosts — see regulated & air-gapped for what that does and doesn't mean.