Almost none of the code behind a modern webshop or booking system was written by the people who own it. A single project quietly pulls in several hundred ready-made packages, written by strangers, updated on their own schedule — and any one of them can take your business offline or leak your customers' data. CodeControl connects to your code once and keeps answering the question you can't answer today: do we know what we're running, and is any of it dangerous right now?
Read-only access to the repositories you choose · Your source code is never stored · Part of the TrustCtrl platform
When a website looks right in the browser, it feels finished. But the things that actually cause a breach leave no trace on the screen: an out-of-date package with a published flaw, an API key someone pasted into the code, a package that only pretends to be the one you wanted. None of it shows up in testing. All of it ships. CodeControl sits between "it works" and "it's live" and tells you, in plain language, what's about to be released — so an invisible mistake becomes a visible decision.
Nobody reads several hundred packages — not you, not your developer, not your agency. CodeControl reads them for you and reports only what has a name, a version and a consequence: this package, this flaw, this is what to do.
A password committed at 14:00 is reported at 14:01 — not at the next monthly review. And when a new pull request is opened, the same check runs on just the new lines, while fixing it still takes a minute.
Code you haven't touched in a year can become dangerous overnight, because the flaw was published this morning. Every night CodeControl re-checks what you run against what the world now knows about it.
AI-generated code is extraordinarily good at working. It is far less good at the part nobody sees: which library the assistant chose, whether that library is still maintained, whether it even exists, and whether the example key it helpfully filled in is now committed to your repository forever. The result runs beautifully and carries risk that nothing in your normal testing would surface. That gap is exactly what CodeControl was built for.
AI assistants sometimes recommend a package name with total confidence — one that was never published. Attackers watch for those names and register them, so the next project that asks gets working code with a passenger. CodeControl flags brand-new packages before they become part of your product.
The single most common serious mistake in software, and the easiest one to make when you're moving fast. CodeControl finds them in the code — and in the history, where they stay recoverable long after somebody deleted the line and assumed that was the end of it.
Every finding has a Copy AI fix prompt button. It hands your assistant the whole picture — what's wrong, why it matters, the recommended fix, how to verify it, and the ground rules that stop it changing things it shouldn't. You fix it where you already work.
You connect GitHub once. From then on, every dependency your project declares — and every dependency those dependencies pulled in — is checked against all thirteen, continuously. They're grouped into nine below; the technical page lists all thirteen separately. Each becomes its own finding you can act on, park with a reason, or watch close itself when it's fixed.
Somebody has already published exactly how to break this. We check every package you depend on — including the ones your packages pulled in without asking you.
The difference between a list of 31 problems and a list of 3 to fix this week. We cross-check every finding against the official catalogue of flaws confirmed to be exploited in the wild.
Packages published specifically to steal credentials or install a backdoor — and typosquatted packages named one character away from the popular one, waiting for a typo.
API keys, payment credentials and database passwords committed by accident. Secret scanning runs over the working tree and over every pull request, because one leaked key can mean a bill nobody authorised, or a customer database nobody meant to share.
Deleting the line doesn't delete the secret — it stays recoverable in the project's history. Most people believe otherwise, which is why this one is worth checking.
Packages years behind, packages past end of life, and packages whose author has walked away. Yesterday's safe version is tomorrow's vulnerability, and nobody is going to fix an abandoned one.
Some open-source licences oblige you to publish your own source code. Discovering that during an investment or an acquisition is an expensive way to find out.
The Docker base image your software runs in, and the GitHub Actions workflow that ships it to production. Both hold real power — the pipeline holds your deployment credentials — and both are routinely forgotten.
Every package, version and licence, exportable as a Software Bill of Materials — the standard document your insurer, your enterprise customer or your auditor is increasingly likely to ask for by name, in both of the formats they name: SPDX and CycloneDX.
Background reading: what to decide before letting an AI agent write code, how software supply chain attacks actually work, what NIS2 asks of you as a supplier, which licences reach your own product, what to do when a dependency is abandoned, what an SBOM is and who will ask you for one, why most of your dependencies are ones you never chose, how KEV and EPSS decide what to fix first, and why deleting a committed API key does not remove it.
Each of these is documented in full — how it's detected, where the data comes from, and what it deliberately doesn't claim. Read how each check works — the full technical description
Any tool can produce a list — GitHub does it for free. The reason those lists get ignored is that they don't say where to start, and a security tool that gets ignored protects nobody. CodeControl opens with patch these first: usually two or three items, chosen because they're confirmed to be under active attack or statistically likely to be next. Everything else is ordered behind them. That ordering is the part that turns a list into a plan.
Most risky packages are ones you never chose — they arrived with something else. Every finding shows the chain that pulled it in, so you know which single upgrade clears it.
The repository page gives you the smallest set of commands that clears the list, ready to copy. Where no safe upgrade exists yet, it says so — and keeps watching for one every night.
You'll be emailed for a malicious package, a committed secret, or a dependency that just started being exploited. Never for the routine backlog — that's what the dashboard is for.
The rest of TrustCtrl is built so a business owner can act alone. CodeControl is different, and we'd rather say so before you buy than after. Every finding is still written in plain language, and every fix comes with steps and a prompt you can hand to an AI assistant — but to act on it, someone needs access to the code and permission to change it. If that's you, your developer or your agency, you'll get a great deal out of this. If nobody on your side can push a change, buy the rest of the platform first.
You have code on GitHub — written in-house, by an agency, or with an AI assistant — and someone who can update a package, rotate a key or open a pull request. You don't need security expertise; that's the part we supply.
Your site is a hosted platform you don't have code for — a standard Shopify, Wix or Squarespace shop. There's nothing for CodeControl to read. VulnControl checks that kind of site from the outside instead.
If an agency writes your software, CodeControl quietly answers something awkward: is our supplier keeping it current? Not as an accusation — as a shared, dated report you can both look at.
The established supply-chain tools are good, and we're deliberately measured against them. Where we go further is in the three places their reports tend to lose you: what to fix first, why you even have the package, and honesty about what wasn't checked.
Every lookup that fails is reported as not checked, with the reason. A package whose version can't be established is listed as unverified, never assumed fine. A report that occasionally lies in the reassuring direction is worse than no report.
Every build is tested against a planted repository with a written-down answer key: miss a real problem or invent a fake one and the build fails. After release, customers can mark a finding as wrong, and we count it. Precision isn't a claim here, it's a number.
The big tools assume a security team. Most of the businesses we work with don't have one — so the fix arrives as commands to run and a prompt to paste, not as an identifier you're expected to go and research.
The full side-by-side comparison, including what we deliberately don't do, is on the technical page. See the comparison
There is nothing to install on a server, nothing to configure, and no ongoing work. Setup is one click and a choice of which repositories we may read.
One button in TrustCtrl creates and installs it. You choose exactly which repositories it can see — and only those.
The App gets the minimum GitHub offers: permission to read the code you selected. It cannot write to your code, open pull requests or change a setting.
A full scan every fortnight, a re-check for newly exploited flaws every night, and an immediate scan whenever code is pushed. Your source code is analysed in memory and never stored.
A Software Bill of Materials (SBOM) is a machine-readable list of every package your software contains, with its version and licence — the ingredients label for software. It used to be a question only large companies were asked. Now it arrives as a supplier questionnaire, an insurance renewal, or a condition in an enterprise contract — because NIS2 already requires supply-chain security from the companies in scope, and the EU's Cyber Resilience Act phases in a documented bill of materials across 2026–27. Most companies answer with a spreadsheet or a shrug. CodeControl answers with a generated document, from a real scan, dated — in both of the formats that get asked for by name.
Code written by an AI assistant is usually correct, which is not the same as safe. AI assistants pick libraries without checking whether they're maintained, still supported, or even real, and they routinely leave example keys and passwords in the code. None of that shows up when you test the site in a browser — it works perfectly and carries the risk anyway. CodeControl checks exactly those things: every package that came along for the ride, every credential left behind, and which of them is being exploited right now.
It's safe to build with and risky to ship without a check. Vibe coding — describing what you want and letting an assistant write it — produces software that works, quickly, and the person reviewing it usually isn't equipped to spot what came along for the ride: an abandoned library, a package that was never published until an attacker registered the name, an example key left in a config file. None of that is visible in a browser. CodeControl is the gate between “it works” and “it's live”.
To understand it, no — every finding is written in plain language, with what it means and how urgent it is. To act on it, someone needs access to your code: you, your developer or your agency. That's why we say it plainly before purchase. If nobody on your side can change the code, the other parts of TrustCtrl will serve you better.
We read the repositories you select, with read-only permission — the minimum GitHub offers. The code is analysed in memory during the scan and never written to disk or stored. Findings record a file name, a line number and a masked preview; the actual value of a secret is never retained, and never sent anywhere.
GitHub's free Dependabot alerts tell you which packages have published flaws. CodeControl starts there and adds the parts that make a list actionable: which handful is actually being exploited, why you have the package at all, whether credentials are sitting in your code or history, whether a package is malicious, unmaintained or brand new, what your licences oblige you to do, and a bill of materials you can hand to an auditor. It also tells you what it could not check, instead of showing you a clean result.
No. Those are hosted platforms where you don't have your own codebase, so there's nothing for CodeControl to read. VulnControl checks that kind of site from the outside — identifying the software it runs and matching it against known vulnerabilities — and the rest of the TrustCtrl platform covers uptime, certificates, site quality, email and brand.
It doesn't analyse your own hand-written code for programming flaws, and that's a deliberate choice: for this audience the code you wrote is a small fraction of what you actually run, and that kind of analysis produces more false alarms than anything else in security. It also isn't a penetration test — it reports what can be known from the repository, not how the live application behaves.
Connect one repository and see the first report — what you depend on, what's dangerous, and which two or three things to fix this week. CodeControl is part of the TrustCtrl platform.
Read-only access · Source code never stored · Full technical description