What Monterva checks
The analysis it runs, the languages it covers, and the things it deliberately does not look for.
Monterva runs established open-source analysis tools, each with configuration we control, and translates their output into one consistent shape.
What it looks for
Committed credentials. API keys, tokens and other secrets checked into the repository. This is consistently the highest-value category, because the exposure continues for as long as the key is valid — and rotating it is something only you can do.
Dependency advisories. Your lockfiles are read as data and checked against a public advisory database. Six lockfile formats are understood. Dependencies are never installed to do this.
Common code weaknesses. Patterns with a track record of causing incidents: queries built by joining strings together, shell commands assembled from user input, disabled security checks, unsafe rendering of untrusted content.
Language-specific analysis for the languages the tooling supports, using rules chosen to be explainable rather than exhaustive.
What it does not do
- It does not run your code, your tests, or your build.
- It does not install your dependencies.
- It does not load your repository's linter or analyser configuration — which means a rule you have disabled in your own configuration is still reported here. That is deliberate: an audit the repository under review can edit is not an audit. If a finding is a known and accepted risk, mark it as such in Monterva.
- It does not check running infrastructure, cloud configuration, or anything outside the repository.
- It does not attempt to exploit anything. Nothing here is a penetration test.
Where a lockfile is missing
If a repository has no lockfile, dependency findings cannot be produced, and the report says that explicitly rather than showing an empty dependency section. The same applies to a language nothing here analyses: it is detected, named, and reported as not covered.
Why some findings ask for a human
A pattern match is evidence, not a verdict. Where the tooling cannot tell whether a match is a real problem in your particular code, the finding is marked as requiring human review rather than presented as settled. A confident wrong answer is worse than an honest uncertain one.