Git provider support

Code Security and Dependency Scanning scan repositories hosted on GitHub, GitLab, Azure DevOps, and Bitbucket. The scans themselves are the same on all four. Pull request checks, autofixes, self-managed instances, and compliance monitoring depend on the provider.

You need to be an admin to connect a provider or change a repository’s settings. Azure DevOps and Bitbucket are in beta.

Support by provider

Feature	GitHub	GitLab	Azure DevOps (Beta)	Bitbucket (Beta)
Static analysis and secrets scans	✅	✅	✅	✅
Dependency Scanning and SBOM	✅	✅	✅	✅
Daily scans and manual scans	✅	✅	✅	✅
Scan on every push to the target branch	✅ – with code security pull request checks on	✅ – in beta, with code security merge request checks on	❌	❌
Code security checks on pull and merge requests	✅	✅ – in beta, with the api scope on the token	❌	❌
Dependency vulnerability checks on pull and merge requests	✅ – in beta	✅ – in beta, with the api scope on the token	❌	❌
Autofixes opened as pull or merge requests	✅ – with autofixes on for the connection	✅ – with the api scope on the token	❌	❌
Self-managed instance	❌ – github.com only	✅	❌ – dev.azure.com only	❌ – bitbucket.org only
Clone over SSH	❌	✅	❌	❌
Provider configuration monitors	✅ – from a separate integration, GitHub (Cloud Security)	✅	✅ – organization and user settings only	❌
Code review evidence	✅	✅	❌	❌

You can’t add a repository by its git URL, so a repository hosted anywhere other than these four providers can’t be scanned.

GitHub Enterprise Cloud with data residency, where your organization is hosted on a ghe.com address, isn’t supported. An Enterprise Cloud organization hosted on github.com connects like any other organization.

Connect a provider

1. On the Code security page, click Connect version control. The integrations directory opens, filtered to the providers that work with Code Security.
2. Pick GitHub (Code), GitLab, Azure DevOps, or Bitbucket, and complete its connect form.
3. Back on Code security, click Select target repositories. Select the repositories to scan, choose a target branch for each, and click Add repositories.
4. Set the scanner sensitivity and click Finish & start scan.

Connect version control appears only until you connect your first provider. After that, add providers from Integrations > Add integration.

The repository list leaves out archived GitHub repositories, archived GitLab projects, and disabled Azure DevOps repositories. A GitHub or GitLab connection whose credentials have been revoked adds nothing to the list and shows no error, so if one connection’s repositories are missing, check its credentials first.

GitHub

Connect GitHub (Code), which sends you to GitHub to install an app. GitHub (Cloud Security) is a separate integration that covers Oneleet’s other GitHub features, and its repositories can’t be scanned.

Use a GitHub account with administrator privileges, because installation requests from other accounts fail.

By default, the Autofixes option on the connect form is on, which installs the read-write Oneleet Code app so that Oneleet can open pull requests. Turn it off to install the Oneleet Code Read-only app instead. After you connect, the connection card shows a Read-write badge only if the connection allows autofixes.

GitLab

Create a group access token with the Maintainer or Owner role. Give it the read_api and read_repository scopes for read-only scanning and monitoring, or api and read_repository if you also want Oneleet to open merge requests for autofixes. When you connect, Oneleet works out which kind of token you gave it. Only projects the token is a member of appear in the repository list.

For a self-managed GitLab instance, enter its address, starting with https://, in GitLab instance URL (optional). For gitlab.com, leave the field blank. Scanning, the repository list, and the branch list all use your instance’s address.

By default, Oneleet clones over HTTPS with the access token. If your group doesn’t allow that, switch on Clone over SSH.

Oneleet generates a keypair for the connection and shows you the public key once you’ve connected. Add it as a deploy key under Settings > Repository > Deploy keys in one GitLab project, then enable it on each additional project. To see the key again later, click View SSH key.

Azure DevOps

To connect Azure DevOps, enter your Microsoft Entra tenant ID on the connect form and sign in with Microsoft Entra ID. Sign-in is limited to that Entra tenant. Oneleet finds repositories only in the organizations the connecting user belongs to, and lists each one under its organization and project.

The repository and branch lists come from the integration’s last sync rather than straight from Azure DevOps, so a repository or branch you’ve just created doesn’t appear until the next sync. Integrations sync automatically many times a day.

Bitbucket

To connect Bitbucket, sign in to Bitbucket and approve access to your account, projects, and repositories.

As with Azure DevOps, the repository and branch lists come from the integration’s last sync rather than straight from Bitbucket, so a repository or branch you’ve just created doesn’t appear until the next sync. Integrations sync automatically many times a day.

Scan repositories

By default, Oneleet scans each repository’s target branch once a day, whichever provider hosts it. You can also run a scan yourself with Start rescan.

Each repository has one target branch, which defaults to the provider’s default branch. You can’t limit a scan to one folder of a monorepo.

To stop the daily scans for a repository, open it under Code security > Config > Repositories and click Disable automatic scans. After that, the repository is scanned only when you start a scan yourself.

Check pull requests

Pull request checks run on GitHub pull requests and GitLab merge requests (GitLab’s name for pull requests). Code security pull request checks look for new findings, and dependency pull request checks look for new dependency vulnerabilities. Both kinds are in beta on GitLab, and dependency pull request checks are in beta on GitHub too. To use either kind while it’s in beta, ask us to turn it on for your workspace.

By default, both kinds are off. To turn them on, go to Code security > Config > Repositories and open a GitHub or GitLab repository that has automatic scans enabled. Under GitHub pull request checks, select Automatically scan pull requests for new findings for code security pull request checks, Automatically scan pull requests for new dependency vulnerabilities for dependency pull request checks, or both. Either kind works without the other.

Oneleet then scans non-draft pull requests that target the repository’s target branch and reports the results on each one as Oneleet Code Security Scan and Oneleet Dependency Scan. When a pull request adds or fixes a dependency vulnerability, Oneleet also posts a summary comment on it.

Turning on code security pull request checks also makes Oneleet rescan the target branch on every push to it, in addition to the daily scan. Dependency pull request checks on their own don’t add these scans.

Checks on GitLab

On a GitLab repository, the section is headed GitLab merge request checks, and its checkboxes say “merge requests” instead of “pull requests”. Oneleet skips merge requests from forks.

Checks run only when the connection’s token has the api scope and the token’s owner has at least the Maintainer role on the project. Without them, turning a check on still shows a success message, but no checks run.

Autofixes on GitHub and GitLab

Oneleet can open a code-level fix as a pull request on GitHub or a merge request on GitLab. The Autofix menu appears on a finding only when the repository’s connection allows it: a GitHub connection made with Autofixes on, or a GitLab connection whose token has the api scope.

Once you merge an autofix, Oneleet rescans the repository. On GitHub, the rescan starts when the pull request is merged. Oneleet checks GitLab for merged merge requests periodically, so a rescan there can start a few minutes after the merge.

On GitLab, merge requests can’t include changes to binary files. Self-managed instances older than GitLab 15.5 can’t report a token’s scopes, so Oneleet treats their connections as read-only and doesn’t offer autofixes.

Compliance monitoring and evidence

The Code Security monitors check that each repository has code security scanning enabled, dependency scanning enabled, and a software bill of materials maintained. Like the provider configuration monitors below, each one runs only if it applies to your workspace’s compliance programs. When a Code Security monitor runs, it covers every connected repository on all four providers.

Monitors that check the provider’s own configuration, such as code approval and two-factor authentication, depend on the provider:

• GitHub: The monitors belong to the GitHub (Cloud Security) integration, so connect it alongside GitHub (Code) if you want them.
• GitLab: The monitors come with the same integration you use for scanning.
• Azure DevOps: The monitors cover organization and user settings such as sign-in and guest access, with none for repositories or branches.
• Bitbucket: There are no configuration monitors.

Collect code review evidence gathers merged pull requests and merge requests from GitHub, through either GitHub integration, and from GitLab. It doesn’t collect from Azure DevOps or Bitbucket.