Security

What fast-written code leaves behind.

Code written with an assistant arrives working. What it also arrives with is a key pasted into a file, a route that checks who you are next to one that does not, and the same logic in four places. None of it fails a test. MLReps reads the repository and says what it found — and what it could not read, which is the half that decides how much the rest is worth.

A credential someone pasted in and forgot

13 credential formats, each one anchored on the shape of the credential itself rather than on a variable called secret — a private key block, an AWS access key id, GitHub, Slack, Stripe, Google, npm, SendGrid, a model provider’s key, a signed token, a password inside a connection string.

Held to a 99% precision bar. A scanner that flags a line of your schema is a scanner people switch off, and then the real one goes unread too.
The finding records the file, the line and what kind of thing it was. Never the value. A tool that writes your key into its own database has moved the problem, not found it.
Credentials found anywhere on the way out are replaced whole before anything leaves the process — including one split across a line break, so no fragment escapes.
Published example credentials are not reported. AWS prints AKIAIOSFODNN7EXAMPLE in its own guides; it cannot be anybody’s live key.

Test directories are not skipped. Real credentials get committed there, and a scanner blind to test code is blind exactly where people are least careful.

A door checked here and not there

The rule is not “this route has no authorisation check”. A landing page, a sign-in screen, a health check and a webhook are all meant to be reachable by anybody, and a tool that reports every public route buries the one that matters.

What is worth saying is an inconsistency: /own checks who is signed in and /own/review does not, in an application where nesting does not inherit the check. That is a door somebody left open while believing they had closed it — and it is exactly what happens when two routes are written in two sittings.

It degrades safely in both directions. A codebase with no authorisation anywhere has nothing to be inconsistent with and gets no findings; a route with no checked ancestor gets no claim made about it at all.

The rest of what runs, and the one that does not

A dangerous sink

a shell or an evaluator handed a string built at run time — a weaker claim than taint analysis, and worded as one

Install scripts

a package this project publishes that runs a script on whoever installs it

Decoded code executed

your own code doing something that looks like an attack — a different accusation from a dependency being compromised, and kept separate

Copied word for word

the same logic in several places, which is what an assistant produces when asked the same question twice

Untrusted input to a sink

not running. It needs to know where untrusted input enters, which means route extraction we have not built — so it is registered, switched off and said, rather than running without the knowledge its premise needs

Advisory databases, registry metadata and maintainer history are all real inputs to this and none of them is available to a scan that does not call out. Those rules are not written as rules that quietly find nothing.

And the part nobody else will tell you

A rule that did not run is not a clean result, and a region the scan could not read is not a safe one. MLReps draws both, on the same screen as the findings.

How much of the repository was read, as a figure that floors — with anything unresolved it reaches 99 and never 100.
The call sites no static tool can resolve are drawn on the same scale, outside the figure, so they are neither counted in it nor quietly dropped.
A report with nothing resolved draws an empty, dashed track and says not known. No count in it is a zero, because nothing was counted.
Which rules could not run on your repository, by name, beside the ones that did.
There is no security grade. Four repositories of twenty in our corpus had a finding, and fewer than five is not a percentile — so that index is left uncomputed rather than invented.

Read it without connecting anything

One command, in your own checkout. Your source never leaves the machine on this path — there is no column in our schema that could hold it.

npx mlreps setup

What that command does →

Or let it read pull requests

The GitHub App leaves a check run on a pull request. It is always neutral: no branch of our code can fail your build, and nothing about reading your pull requests writes to your repository.

Every scope it asks for →

A finding is information, not advice

We never commit a fix to your repository. No push to your default branch, no merge, on anybody’s behalf. We produce a patch; you apply it, your tests run it, you commit it under your name. The one pull request the App can open is an instrumentation file you asked for.

The other half of fast code

The same scan finds the database query a loop runs once per item, and counts it in the requests you actually served.

What it finds, and what it cannot see →

Every claim here is a property of how the software is built rather than a promise about how we behave, and Security names the build gate behind each one — written to be forwarded unedited to a security team. What we do with your code is on Privacy.