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 pull request checks on	❌	❌	❌
Pull request checks	✅	❌	❌	❌
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 on GitHub

By default, pull request checks are off. To turn them on, open a GitHub repository that has automatic scans enabled under Code security > Config > Repositories, and select Automatically scan pull requests for new findings under GitHub pull request checks.

Oneleet then scans each pull request that targets the repository’s target branch and reports the result as a check named “Oneleet Code Security Scan”. Draft pull requests aren’t scanned.

Turning on pull request checks also makes Oneleet rescan the target branch on every push to it, in addition to the daily scan. This is the only way to get push-triggered scans, so they aren’t available on the other three providers.

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.