Legal technology

Client material stays inside the firm, including in your build pipeline.

The systems that hold matters are the easy part to think about. The harder question, and the one that turns up in client questionnaires, is which outside parties touch the code behind them: the code carries the matter taxonomy, the work-product separation and every rule that keeps one client’s material away from another. Vulkro reviews that code without taking a copy of it, which is what keeps the answer to that question short.

Start the 14-day trial What an audit asks for →

Nothing is uploaded
Matter-boundary checks
Answers for a client questionnaire
Runs on the firm’s own machines

01 / The duty

Confidentiality reaches further than the document store

The obligation is to take reasonable steps against inadvertent disclosure, and it does not stop at the edge of the firm. It follows the vendors, the platforms and the tooling the work depends on.

In the United States the common reference point is the American Bar Association’s Model Rule 1.6 and the guidance built on it; other jurisdictions phrase the same duty differently and sometimes more strictly, and most corporate clients add outside counsel guidelines on top with their own list of what may be shared and with whom. The details differ. The direction of travel does not: the firm stays responsible for material it lets a third party hold.

The code behind a matter system is more revealing than it looks from outside engineering. It carries the matter taxonomy and which documents belong to which engagement, the work-product separation the firm relies on, the redaction and tagging pipeline, and every access rule that enforces the boundary between clients. A copy of it does not contain a single privileged document and still describes, in detail, how the privileged documents are handled and how the boundary could be crossed.

That is why the answer to the next question matters more here than in most sectors. Whether an analysis service that ingests that code counts as a party with access to confidentiality-relevant material is arguable, and arguing it is the problem: the argument has to be made to every client who asks. Vulkro takes no copy, so the argument does not start.

This page is not legal advice, and nothing on it is a determination about your obligations. What it describes is an architecture: the review runs on your own machines and no source code is transmitted anywhere.

02 / Client due diligence

The questionnaire, and the answers you can give

Legal-technology procurement runs on questionnaires, and the awkward rows are always the ones about third parties and about where data goes. These are the rows a review tool shows up in.

Six rows from a client security questionnaire, and the answer a locally run review supports for each one.
The question	The answer the architecture supports
Which third parties can access source code or systems that process our matter data?	The security review is not one of them. It runs on the firm’s own machines and build runners, reads files from disk, and writes its report beside them. No copy of the code exists anywhere else.
Where is our data processed, and where are the results stored?	Wherever the machine that ran the review already is. Findings, reports and evidence packs are files on your own infrastructure, under your own retention schedule, which is also the answer to the deletion question further down most questionnaires.
Do you perform application security testing, and how often?	On every build, in the pipeline that produces the release, with a check that fails on newly introduced high-risk issues. Each result is dated and repeatable, so two of them can be laid side by side.
How do you evidence separation between clients and matters?	An inventory of every endpoint the application declares, with the ones reachable without a session marked, and the isolation checks in section 03 run against the code behind them.
What happens for a walled matter or an isolated environment?	An air-gapped installation carries its entitlement in a licence file on disk and makes no network call at all. The vulnerability database is carried in as a checksummed file.
Is a data processing agreement in place with your code analysis vendor?	There is no transfer of your code to cover. The one call that leaves the machine confirms the licence and carries a short list of usage fields, itemised in full on the trust page: no file names, no project names, no findings.

The data-handling statements above are the binding ones published on the trust page and in the privacy policy, and the outbound call is itemised field by field there. Nothing on this page is legal advice, and whether a given answer satisfies a particular client, insurer or set of outside counsel guidelines is a judgement for the firm.

The reason this reads as a table rather than as a sales argument is that it is the format the questions arrive in. Every row is backed by something a client can check for themselves.

03 / Matter boundaries

What a boundary failure looks like in the code

In most products a broken separation between tenants is an incident. In legal technology it is a disclosure, which is why these shapes are worth a section of their own even though none of them is unique to the sector.

The boundary is taken from the request: A handler that reads the matter or team identifier out of the request body or a query parameter rather than from the session. The caller then chooses which boundary they are inside, which is not a boundary.
A query that forgot its filter: One lookup among fifty that fetches by document or matter identifier alone while its siblings scope to the team. This is the single most common way one client’s material appears in front of another.
A cache key with no matter in it: A result cached under a key that identifies the query but not the caller, so the second request for the same document is served whoever asks. The access check passed; the cache answered before it ran.
Background work that inherits a boundary it never re-checks: An export, a bulk tag or an indexing job that was enqueued inside one matter and executes outside any. The original check happened at request time and nothing revalidates it at run time.
An administrative route with a broken scope: Internal tooling that was written for one team and grew a search across everything. Administrative endpoints are where matter separation is most often assumed rather than enforced.
Identifiers in places that keep records: Client names, opposing party names and matter numbers reaching log lines, error reports and analytics. Those destinations have their own retention, their own access lists and often their own vendors.
Credentials for the document store: Object storage keys committed to the repository. The access controls on the matter system are irrelevant if the credentials for the bucket underneath it are in the source history.

vulkrobot · commented just now

HIGHMatter documents are fetched without a team scope

routes/matters.ts:61VULK-2117CWE-639

The handler looks the matter up by the identifier in the path and returns its documents. Nothing ties that lookup to the caller’s team, and the authentication middleware only proves somebody is signed in. Any signed-in user can read another team’s matter by changing the number in the URL. The other four handlers on this resource scope the query; this one does not. The check belongs in the query rather than in the response.

Suggested change

Line before	Line after	Change	Source
@@ -61,7 +61,11 @@ router.get('/matters/:id/documents')
61	61		router.get('/matters/:id/documents', requireAuth, async (req, res) => {
62		-	Removed line. const matter = await db.matter.findUnique({
63		-	Removed line. where: {id: req.params.id},
	62	+	Added line. const matter = await db.matter.findFirst({
	63	+	Added line. where: {id: req.params.id, teamId: req.user.teamId},
64	64		});
65	65
	66	+	Added line. if (!matter) {
	67	+	Added line. return res.status(404).send('not found');
	68	+	Added line. }
	69	+	Added line.
66	70		return res.json(await listDocuments(matter.id));
67	71		});

Re-scanned. Finding no longer reported, file still parses.verified before posting

vulkro scan · exit 1 · 1 high, 0 criticalRan on your own runner. The code never left it.

The same finding as it arrives on a pull request: what is wrong, why it is wrong, and the change that closes it.

The comparison against sibling routes is the useful part. A handler that is missing a check its four neighbours perform is a much stronger signal than a handler that looks unusual on its own, and it is the shape that catches a boundary that was correct until somebody added one more endpoint in a hurry.

04 / Evidence and scope

What procurement asks for, and what this is not

Legal-technology buyers and the firms that insure them ask for two frameworks more than any others, and the review produces evidence against both.

The evidence pack maps findings onto the SOC 2 Trust Service Criteria and the ISO/IEC 27001:2022 Annex A controls, which are the two that appear in nearly every legal-technology procurement pack and in most cyber insurance renewals. For matter data belonging to European or United Kingdom clients there is also a security-of-processing evaluation against Article 32 of the General Data Protection Regulation, and a separate record-of-processing document in the Article 30 shape rendered from the data-flow lineage of the scan.

The boundary is worth stating plainly. The review reads your engineering codebase, not your document corpus: it never opens a client file, does not classify documents, and has no view of what is privileged. It finds code-level failure shapes, credential exposure and identifier leaks. It does not review your intake or conflicts process, it is not an information governance programme, and a clean result is not an ethics opinion. It is also not a penetration test: it reads code and does not touch a running system.

Everything else about audit evidence is shared with the other regulated sectors and lives one level up: what an auditor asks for, which frameworks are mapped, and why none of it requires sending your code anywhere. The binding data-handling commitment is in the privacy policy, and the European data-protection mapping is in the compliance docs.

The review, and the red team

Vulkro reviews your codebase. Vulkro for Salesforce reviews your Salesforce build, which is where a good deal of matter intake, billing and client management runs. Vulkro Red is the other half of the team, taking what the review found and working out what an attacker would do with it.

The reviewVulkro

Reviews your code

Goes through every line of your codebase before a release, the way a senior engineer would if they had the time, and tells you what a customer could exploit.

You get: what to fix, and a pass or fail on the releaseWhat it checks

Vulkro for Salesforce

Reviews your Salesforce build

The same review for the part of your business that runs on Salesforce, including the settings in the org itself, and what the AppExchange security review will ask you for.

You get: a straight answer on whether you are ready to submitVulkro for Salesforce

The red teamVulkro RedComing soon

Attacks what they found

Takes the review and works out what an attacker would actually do with it: which small problems chain together into a real break-in, and which ones are noise.

You get: the attack, step by step, before someone else runs itHow it works

One engine behind all three, so the red team works from what the review already foundIt all runs on your machine. Your code never leaves it.