Your client matter code stays on the machine that wrote it.

Legal-tech engineering carries a confidentiality property that makes cloud SAST awkward. The application code references the schemas, the access-control logic, and the dataflow that processes privileged communications, attorney work product, and client matter content. Uploading that code to a third-party vendor is, depending on the matter and the jurisdiction, a confidentiality event that needs to be papered.

Vulkro is the offline option. The scanner runs on your laptop or your CI runner, never phones home, and produces no record outside your infrastructure. The "did we share privileged code with a third party" line of the next due-diligence questionnaire stays clean.

Attorney-client privilege and cloud SAST​

The American Bar Association Model Rule 1.6 (and equivalents in EU, UK, Canadian, and Australian jurisdictions) require lawyers to make reasonable efforts to prevent inadvertent disclosure of client confidences. The "reasonable efforts" standard extends to the firm's vendors and to legal-tech products the firm uses.

Most legal-tech engineering happens at one remove from the firm: a product vendor builds the doc-review platform, the firm uses it. But the same principle flows through. The application code that processes privileged documents references:

• The matter taxonomy (which documents belong to which engagement)
• The work-product separation (the firm's privilege boundary)
• The dataflow that handles, redacts, and tags privileged content
• The access-control logic that enforces matter-level boundaries

A SAST vendor that ingests that code is, in a reasonable interpretation of the privilege rules, a downstream party with access to privilege-relevant information. The "the source code is not the privileged document" distinction is technically correct but commercially uncomfortable: most legal-tech buyers will ask the question, and the answer "yes, our scanner vendor also receives our code" is the harder one to defend.

Vulkro receives no code. The binary runs locally, reads files on your filesystem, writes a report. No account, no telemetry, no upload, no remote control plane. The privacy policy is short and binding: the company that publishes Vulkro never receives your source code, ever. The manifesto covers the architectural commitment in full.

Use cases we hear from​

Document review and e-discovery platforms. TAR / CAL / predictive-coding pipelines reading privileged content; production set generation; redaction tooling. The scanner runs against the engineering codebase, not the document corpus, but the architecture conversation is the same: your SAST tool should not be a third party with read access to code that handles privileged content.

Matter management and practice management. Time tracking, billing, conflict checking, and matter-taxonomy systems. The client-name and matter-number fields are confidential even when the document content is not; access-control bugs on matter views are a confidentiality event in the same family as privileged-document leaks.

Contract analytics and CLM platforms. Contract review, playbook automation, redlining, contract lifecycle management. The contracts under review are confidential under the firm's duty to its corporate clients; the engineering codebase referencing the schemas needs the same offline-scan property as document-review tooling.

Litigation analytics. Outcome prediction, judge analytics, opposing-counsel research. Mixed confidential content; mostly the data sources are public records, but the firm's choice of which strategies to research is itself attorney work product.

Court technology and e-filing. Public-facing systems that handle sealed records, in-camera filings, and PII embedded in court documents. Vulkro's PII catalog plus the auth-dataflow detector covers the same shapes that show up in healthcare contexts.

At a glance: Vulkro vs SaaS SAST on privilege preservation​

The "vendor never receives code referencing privileged content" property is the load-bearing one. It is the property your firm's general counsel will care about; it is also the property a cloud-first SAST vendor cannot match without architectural surgery.

What Vulkro catches that legal-tech regresses on​

The same detector families that work in healthcare and fintech apply here:

• Access control on matter boundaries. auth_dataflow and idor find endpoints that load matters by id without an ownership check or a matter-team membership check.
• PII / PHI / client-identifier leaks in logs. The pii family catches client identifiers, opposing-party names, and matter numbers flowing into log files, error messages, or third-party telemetry.
• Cross-tenant data leaks. For multi-tenant doc-review platforms, mass_assignment and tenant-scoping checks catch the "wrong tenant's matter visible to user" failure shape.
• Document storage credential exposure. secrets covers the cloud-storage credential families (S3, Azure Blob, GCS) that hold the document corpus.

Run vulkro scan to see the full list against your codebase; the CLI reference covers the flags.

vulkro compliance profiles relevant to legal-tech​

The Free tier ships compliance-mapping output against published frameworks. For legal-tech, the relevant profiles are:

• gdpr for EU and UK matter data
• soc2 for the general trust framework your firm's cybersecurity insurance and DDQ process will reference
• iso27001 for ISO-aligned engagement environments
• nist-ssdf for federal and state-government legal work

Run vulkro compliance --help for the live list. The Pro compliance-pack output renders the signed evidence pack for SOC 2 and ISO 27001 (the two most-asked-for frameworks in legal-tech procurement).

Talk to us​

If you are evaluating Vulkro for a legal-tech engagement and want to walk through the privilege-preservation argument, the compliance mapping, or the air-gap deployment recipe, email [email protected].

Read the manifesto for the architectural commitment. Read the privacy policy for the binding data-handling commitment. See the benchmark for reproducible detection numbers.