RedKit · Code scans
Scan your GitHub and GitLab repositories, private ones included, for leaked credentials, vulnerable dependencies, supply-chain risks and unsafe CI.
Code scans look inside your repositories for what attackers look for first: credentials committed by mistake, dependencies with known vulnerabilities, install-time scripts and obfuscated code, and CI workflows that can be abused. They run on the repositories of your infrastructure, from RedKit → Code.
| Repository proven by | Private repositories | How scans start |
|---|---|---|
| GitHub App | Yes | By hand, on connect, on a schedule, on push |
| GitLab (Cloud) or GitLab (Self-Managed) | Yes | By hand, on connect, on a schedule, on push |
A .mlab file | No, public repositories only | By hand |
What a scan finds
| Area | What is checked |
|---|---|
| Credentials | API keys, cloud credentials, tokens, private keys and passwords in the code. A full scan also reads every branch and the whole git history: a credential deleted from the code but still in an old commit is flagged, so you know to rotate it. |
| Dependencies | Every lockfile is checked against known vulnerabilities, with the version that fixes each one. |
| Supply chain | Install-time scripts, obfuscated or encoded code, sensitive APIs, files that run automatically in an editor or an AI assistant, risky Dockerfiles. |
| CI | GitHub Actions workflows open to injection, triggered unsafely, using unpinned actions or excessive permissions. |
| Inventory | Languages, files and lines of code, for the repository's overview. |
Credentials found by the credential check are shown masked: only the first four and last four characters stay visible. The finding tells you where a credential is and which kind it is, not its full value. To recognise the same credential from one scan to the next, mlab.sh also keeps a fingerprint (hash) of it.
Quick and full scans
- Quick scan: the current state of the default branch. A few minutes. This is what a push starts.
- Full scan: every branch and the whole history, for credentials that were removed from the code but are still valid. Up to around 50 minutes on a large repository; repositories over 2.5 GB are refused.
Launch either from the Scans tab of a repository. A scan runs in the background: you can leave the page and come back.
Automation
The Automation tab of a repository connected through GitHub or GitLab sets when it is scanned without you:
| Trigger | Default | What runs |
|---|---|---|
| On push to the default branch | On | A quick scan |
| When the repository is first connected | On | A full scan |
| Schedule (daily, weekly or monthly, at the hour you choose) | Off | A full scan |
On GitHub, pushes arrive in real time. On GitLab, mlab.sh notices a new commit on the default branch within a few minutes. Only one scan of a repository runs at a time: a burst of pushes does not pile up scans.
Repositories proven by a .mlab file are scanned by hand only.
Results
Each scan is kept in the repository's history with its status (running, completed, partial, failed), the commit it scanned, its trigger and its findings by severity. A scan's page lists every finding with its file and line, linking to the exact line on GitHub or GitLab at the commit that was scanned.
Two webhook events (set them up in Organization settings → Webhooks) tell your tools when a code scan ends:
scan.code.completed: the repository, the scan, its trigger, the commit and the counts by severity, with a link to the results.scan.code.failed: the same, with the reason.
Repository pages
Besides Scans and Automation, a repository connected through GitHub or GitLab shows what its forge knows about it, without leaving mlab.sh:
- Overview: description, languages, visibility, default branch, license, size, activity.
- Activity: commits per week, latest commits and their signatures, contributors, releases.
- Hygiene: how the default branch is protected, signed commits, security policy, code owners, automated dependency updates, committed credential files, and who administers it.
- Webhook events (GitHub): every event GitHub sent about the repository and what mlab.sh did with it.
Access to your code
- mlab.sh only reads your repositories; it never writes to them.
- The read access mlab.sh uses is temporary: one hour on GitHub, two hours on GitLab, renewed for as long as the repository stays connected. Disconnecting the repository, uninstalling the GitHub App or revoking the GitLab authorization ends it.
- mlab.sh does not keep a copy of your repository. It keeps the findings: location (file, line, commit), kind of finding, a short excerpt of at most 300 characters, and for credentials the masked value described above.