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 your proven repositories, from Repositories on code.mlab.sh.
| 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 | Off | 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, code.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 on mlab.sh, in Organization settings → Webhooks) tell your tools when a code scan ends:
scan.code.completed: the repository, the scan, its trigger, the commit, the counts by severity and what is new since the previous scan, with a link to the results. Each repository can limit it to scans with new findings: see Alerts.scan.code.failed: the same, with the reason.
Triage
Tag a finding to record what you decided about it. Select several to tag them in one go.
| Tag | Means | Counts and grade |
|---|---|---|
| False positive | Not a real issue | Left out |
| Accepted risk | Real, and accepted | Left out |
| Review later | Still to look at | Counted |
| Fixed | Fixed in the code | Counted until a scan no longer finds it |
Tags follow your findings
When a scan finishes, the tags of the repository's previous scan are carried over to the same findings in the new one, so a false positive is triaged once, not once per scan. "Same finding" does not depend on the line: a secret is the same when its rule, file and value are; a vulnerable dependency when its advisory, file, package and version are. A finding whose line moved keeps its tag.
- False positive, accepted risk and review later carry over.
- Fixed never carries over: a finding the scanner still sees is not fixed.
- Accepted risk is dropped when the finding climbed to high or critical, so the risk is asked again: the one that was accepted is no longer the one on the table.
To dismiss a whole path or rule rather than one finding, use exclusions.
Repository pages
Besides Scans, Automation and Settings, a repository connected through GitHub or GitLab shows what its forge knows about it, without leaving code.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.