Security and your code

You are handing a third party read access to your source code. This page describes what we do with it, and the design decisions that make each statement enforceable rather than a promise.

Your code is never executed

No dependency installation, no build, no test run, no loading of your repository's own analyser configuration.

This is not caution for its own sake. Installing dependencies executes install scripts — arbitrary code chosen by whoever published those packages. It is exactly the supply-chain attack this product exists to warn you about, and a reviewer that performs it to check for it would be an odd thing to build. Dependency findings therefore come from reading your lockfiles as data and checking them against an advisory database.

The same reasoning covers configuration. A linter's configuration file is a program the linter executes, and loading yours would be remote code execution wearing a reasonable costume.

Your code never reaches our web servers

Analysis happens on a separate machine, inside a container with no network access at all, running as an unprivileged user on a read-only filesystem with memory and process limits. The container holds no credentials — nothing in its environment would be useful to an attacker who reached it.

Snapshots are fetched as archives through GitHub's API rather than cloned, because a clone brings submodules, filter configuration and a .git directory containing hooks.

Your code is not retained

A snapshot exists only for the duration of one review and its working directory is destroyed afterwards — including when the review fails, which is the case where nobody is watching.

What is kept is the findings, a short excerpt around each match so you can see what was flagged, coverage information, and the report. Matched credentials are stored redacted: we record that a key was present without keeping the key. A findings database quietly accumulating other people's live keys would be a worse breach than any it reported.

The language model cannot decide anything

Where explanations appear in a report, they are written by a language model that was given findings which already existed. It has no tools, no access to your repository, no ability to run anything, and no authority over what a finding is. It cannot create one, remove one, or change a severity.

This is enforced structurally rather than by instruction. Explanations are stored separately and matched back to findings by identifier; anything referring to a finding that does not exist is discarded. Delete every explanation and the review is still complete and correct.

What we cannot tell you

Nothing here proves the absence of a problem. Monterva reports what its tools found in the code they were able to read, and states plainly what they could not read. Treat it as one useful input, not as a verdict.

Reporting a security problem

If you find a security problem in Monterva itself, write to hello@monterva.com with "Security" in the subject line. The security page says what to include and how to look without affecting anyone else, and the same contact is published at /.well-known/security.txt.