One security check on every pull request, at a flat price for the whole team. Your code is read on one server in Finland and never sent to an AI model or any third party — only package names and versions go out, to the package registries and their download counters.
The check fails when it finds something serious, so it blocks the merge as soon as you mark it as required. The first report lands about a minute after you install, on the code already in your repository.
Before you trust any of that: we publish how often we are wrong → 83 corrections, each one from a line we got wrong in a real public repository.
We start with the code that is already there, because the mistake we find most often is never added in a pull request at all. After that, every dependency you add gets checked for how old it is and whether anyone actually uses it — the profile of a package an attacker registered last week, which installs without a word and has no advisory yet. Plus hardcoded credentials, SQL built by interpolation, insecure deserialization and model output rendered as raw HTML. Findings land as a comment on the pull request, with the file, the line and the fix.
Here is the measurement that made us build it that way. We looked for one specific
mistake — a service key carrying a NEXT_PUBLIC_ or VITE_
prefix, which the framework ships to every visitor's browser — in 63 real pull requests
from Next.js and Vite projects. It appeared zero times. In the existing code of 8
real repositories it appeared in seven. It gets written once, the day the project
is created, and a tool that only reads diffs will never see it.
We audit public pull requests every day to keep ourselves honest. In more than 1,400 dependencies added by real developers we found no invented packages — the attack everyone writes about is rarer than the headlines suggest, and we would rather tell you that than sell you a scare. What we do find, on about one pull request in fifteen, is credentials and injection. Read the measurement, or see the live count.
Built for European software teams and agencies of five to twenty developers shipping React/Next.js and Python with Copilot, Cursor or Claude — and for the lead who has to tell a client where their code goes. Where your code goes →
Socket.dev does the dependency half better than we do, and you should know that from us rather than from a search. They analyse package behaviour — install scripts, network and filesystem access, obfuscated code — which we do not. Their free plan covers unlimited developers and repositories, up to 1,000 scans a month, and blocks malicious dependencies automatically. If dependency risk is your whole problem, install Socket — for free.
Where we differ is scope. Socket looks at your dependencies; we look at the dependency and the code in the same check — hardcoded credentials, keys shipped to the browser, SQL built by interpolation, insecure deserialization, your workflows and Terraform. If you need both halves on private repositories, their paid tier is $25 per developer per month with a minimum of five; ours is a flat price for the whole organisation. The full comparison →
Prices as published on each vendor's pricing page on 27 September 2026.
We would rather tell you who is better at one half than have you find out later and wonder what else we left out.
“Why not just ask Copilot or Claude to review the pull request?” Do that too, it helps with logic. But whether a package was published last Tuesday is a registry fact, not a judgement, and a model cannot know it. It also means sending your code to one more AI provider — a decision your own clients may want a say in. Different job, different failure mode.
A package that does not exist is not your problem: pip install fails, your
CI goes red, somebody fixes it in a minute. We measured that too — across 1,778
dependencies added in real public pull requests we found zero invented packages,
and we say so on the home page.
The problem is the opposite. The attacker registered the name, so the package
does exist, pip install succeeds quietly and runs their install
script. Now the only thing that can save you is an advisory — and the advisory is not
there yet.
We measured the window. Taking the 100 most recent npm malware advisories and comparing each package's publication date against its advisory date:
During that window every CVE-based scanner reports the package as fine, because there is genuinely nothing to find. But the package is days old and nobody is using it, and that is visible from the registry the moment it lands in your pull request. We do not wait for the advisory. We flag the age and the adoption.
In our sweeps of public pull requests that rule fires on roughly one in every 290 dependencies added by real developers, so it is not a bot that shouts. Both numbers are reproducible against the GitHub Advisory Database and the npm registry without trusting us at all.
These were uploaded to PyPI in the last few minutes. Copy any of them into Copilot, Claude or ChatGPT and ask whether the package exists. It cannot know: every model has a training cutoff, and these were published after all of them. We do not infer existence. We ask the registry.
Live from pypi.org, refreshed every five minutes. If the list is
empty, the query failed and we show nothing rather than invent a name.
The same gates run twice: over the code that is already in the repository the moment you install, and then over every pull request before merge. Findings land as a comment on the PR with the exact file, the line, why it matters and how to fix it. Nobody on your team installs anything.
The install-time pass is deliberately narrower — a diff tells you who wrote a line and when, a whole file does not. It reports credentials and the browser boundary, and stays quiet about heuristics that need that context. We tightened it after running it against our own repository and getting 15 findings, 13 of which were noise.
Every added dependency is resolved against live PyPI and npm. Missing means either an AI hallucination or an unclaimed name an attacker can still register. Reported as critical, with the registry response and the timestamp so you can reproduce it.
The dangerous case: it does exist. Published days ago, near-zero adoption — the exact profile of a slopsquat already claimed. Existence checks miss this. We don't.
Eight key formats with Shannon entropy scoring and false-positive suppression. Emails,
os.getenv() calls and type annotations do not trigger it.
The bugs that only appear in AI-written code: model output piped into
dangerouslySetInnerHTML, service-role keys shipped in
NEXT_PUBLIC_ vars, prompt-injection sinks.
The ones AI writes without thinking: SQL built by interpolation, shell=True
with variables, pickle.load on untrusted data, verify=False
disabling TLS. A correctly parameterised query is not flagged — we got that wrong
once, fixed it, and the regression test that proves it is in the repository.
The version this pull request pins, checked against the GitHub Advisory Database, with
the patched version in the fix line. We only say it when the line pins an exact
version and the affected range can be compared without guessing — a range like
>=2.0 does not tell anyone what will be installed, so we stay quiet
instead of guessing.
Dockerfiles, docker-compose, GitHub Actions workflows, Terraform and Kubernetes.
Including the expensive one almost nobody checks: pull_request_target
combined with checking out the contributor's branch, which runs a stranger's code
with your repository secrets and write permissions. With the ordinary
pull_request trigger we stay silent — that is correct and everyone does it.
And where the fix is not a matter of
opinion, it arrives written. The finding lands on the line with a
suggestion block and a Commit suggestion button:
verify=False becomes verify=True, a vulnerable pin becomes the
version the advisory itself declares patched, an unpinned action becomes the actual commit
SHA with the tag kept in a comment, a hardcoded key becomes the environment read. This is
the one place where being deterministic beats being clever: a reviewer built on a model has
to invent the patch. We derive it — and where it cannot be derived,
we do not offer one. No guessing a UID for you, no patches that need a second line,
nothing in a language where we would not write it correctly. A wrong patch on security code
carries our name and a button inviting someone to apply it without reading.
The same detector runs on your own machine
before you push: python tools/magaudit.py --staged. Exit code 1 if something
serious, 2 if something, 0 if clean — drop it in a pre-commit hook. It is literally the
same code that runs on the pull request, and a test in the repository exists purely to stop
the two from ever diverging. A local scanner that disagrees with CI makes you distrust
both.
Every scanner is wrong sometimes. What decides whether a team keeps it is what happens next — and the usual answer is “open a ticket, or uninstall”. Three ways out, none of which require waiting for us:
Every finding carries a short id. @magaudit ignore a1b2c3d4 in the pull
request, or @magaudit ignore rule VULN-EVAL for all of them. We answer with
a 👍, not another comment. Only repository owners, members and collaborators can do it —
anyone can comment on a public pull request, and if that switched off the detector,
switching it off would be step one of an attack.
An optional .magaudit.yml: paths to exclude, rules to disable, a minimum
severity. It lives in your repository and changes to it go through a pull request like
anything else, so the whole team can see what is being silenced and who decided it.
Coming from another scanner? We honour its annotations:
pragma: allowlist secret, nosec, nosemgrep,
gitleaks:allow, trufflehog:ignore, NOSONAR.
You already answered the question; we are not going to make you answer it twice.
Whatever your settings suppress is still counted and still declared in the comment, with the reason for each one. A tool that goes quiet without telling you how quiet it went is not a tool you can rely on — least of all on the day your own exclusion covers something real.
What we will not do: rewrite a report that was already published. A mute applies from the next audit onwards. Making an already emitted security finding disappear is exactly the capability someone who just pushed a credential would want, and we do not offer it — not even to the owner of the repository.
We are a security vendor asking for access to your repositories. You should not take our word for anything — so we made sure you don't have to.
Every dependency finding ships the exact registry query, HTTP status and timestamp. Run the curl yourself — the finding either reproduces or it doesn't.
Diffs are analysed in memory and never written to disk. The report linked from the pull request keeps the flagged line in memory for up to seven days, then it is gone. We store installation ID, repo name, PR number and risk level — never your source, never a detected secret.
Only package names (and, for the advisory check, the pinned version) leave our
server — to PyPI and npm, to their download counters (api.npmjs.org, and
pypistats.org for Python packages under 90 days old), and to GitHub's own
advisory database. No AI model ever sees your code. That list is the whole list,
and it is the reason we can say we
never test whether a credential you committed actually works: there is nowhere for us to
test it. We chose GitHub's advisory database over the alternatives specifically so the
list would not grow. No third-party analytics,
no trackers, no font CDN. This page counts views and button clicks on our own server
— an event name and a timestamp, no cookie, IP or identifier.
We publish how often we are wrong, derived from the regression tests, not written by hand: each one is built from the exact line observed in a real public repository. See the record →
Hosted in Finland. Webhooks verified with HMAC-SHA256 over TLS 1.2+. GDPR Art. 33 breach notification in 72 hours. Trust and security →
We have no customer logos to show you, because we have no customers yet. This product went live in July 2026. Everything above is a property of the code, not a testimonial — and all of it is verifiable in the report the App generates on your own pull requests. When we have references, they will appear here with names. Until then, the free tier and the scanner at the top of this page are the entire pitch.
Free for public repositories, forever. No SDK, no CI pipeline changes, no per-developer setup. Uninstalling takes one click and removes all access.
Every organisation that processes data for us, what each one receives, how long we keep anything, and the certifications we do not hold — on one page.
Trust and security →
MagSolutionsAI