Git access in Cyberlop: set a read-only token and allowed hosts

Git access in Cyberlop is the token that lets a white-box scan clone your private repositories over HTTPS. An administrator pastes a read-only organisation token into Settings → Git Access and lists the hosts allowed to receive it. Any engineer can also save a personal token under My Account, and Cyberlop tries that one first.

What is Git access in Cyberlop?

Git access is a stored credential that Cyberlop uses to clone a private repository when a white-box scan starts. White-box scans read your source code while testing the running app, so a finding can point to the file and line. Public repositories need no token, because Cyberlop clones them at launch. Private ones do.

Two things always apply. The repository URL must be HTTPS, because SSH (git@) is not supported, and Cyberlop only clones, which means it only ever reads your code. For the repository side of this, see connect a repository.

Which tokens exist?

There are two. The organisation token is shared and sits under Settings. The personal token belongs to one user and sits under My Account. Neither is an API token. API tokens are the secrets your own tooling uses to call Cyberlop; API tokens and permissions covers them.

Why use a read-only Git token?

Cyberlop never writes to your repository, so give it a token that cannot, because a credential should carry only the power its job needs. That is least privilege. The NIST glossary defines it as restricting access to "the minimum necessary to accomplish assigned tasks".

The warning box on the Git Access page makes the same point. Grant read-only access to the repository, all branches included, and nothing beyond that. Most code hosts let you issue a fine-grained token with a read-only contents permission, or a role that can only read. Pick that option when you create the token.

What does leaking a Git token cost?

A leaked token with write access lets someone change your code. A read-only one still exposes your source, so the limits below matter. The numbers on leaked secrets show why.

GitGuardian's State of Secrets Sprawl 2025 found 23,770,171 new secrets in public commits in 2024, a 25% rise on the year before. The same report found that 70% of the secrets leaked in 2022 still worked. It also found that 35% of the private repositories it scanned held at least one plaintext secret. The Verizon 2026 Data Breach Investigations Report puts software vulnerabilities at the start of 31% of breaches. Credentials and flaws are both ways in, so keep tokens narrow and short-lived. See hardcoded secrets and secret scanning.

How do you set the organisation Git token?

Open Settings, choose the Git Access tab, paste a read-only token, list the allowed hosts and save. You need the settings:update permission to change organisation settings, so an administrator normally does this. The table lists each field.

Git Access fields

Steps to set and check the token

1. At your code host, create a read-only token for the repositories Cyberlop should scan. Give it an expiry if your host allows one.
2. In Cyberlop, open Settings → Git Access. The status pill tells you if a token exists.
3. Paste the token into Replace token.
4. In Allowed hosts, type your code host domain. Add more, separated by commas, only if you really use more than one.
5. Click Save Git settings. The pill should now say a Git token is configured.
6. Click Verify to check the saved token.
7. Start a white-box scan on a private repository and check the result for a clone problem.

After you save, Cyberlop encrypts the secret at rest and never displays it again. Its security page adds that git receives the token per invocation and never writes it to disk. The activity feed logs the change as Git Token · Organization with the action "set", which gives you an audit trail.

What are allowed hosts for?

Allowed hosts keep the token from going anywhere you did not intend. Per the help text on the page, the token goes only to the hosts you list, so nobody can collect it by pointing a target at a stray repository URL. Cyberlop clones a repo on any other host without the token and treats it as public.

Example: one host

You keep all private code on one code host, so enter only that domain. If a target's repo URL points elsewhere, Cyberlop sends no credentials. A private repo there fails to clone instead of receiving your token.

Example: two hosts

Some teams keep product code on one host and infrastructure code on another. List both domains with a comma between them. Check that your token can read on each host, or use a personal token for the exception.

Keep the list short. Each extra host is one more place the token can go, and the list works like any allowlist: permit what you need and refuse the rest.

How do personal and organisation tokens differ?

For scans you launch, Cyberlop tries your personal token first. If you have not set one, it falls back to the organisation token. My Account says the same: tokens set there are "used first for scans you launch".

Precedence at a glance

When to use a personal token

Use one when a single engineer can read a private repo that the organisation token cannot. Save it under My Account → Git access token with Save Git token. It applies only to scans that person launches. Everyone else's scans still use the organisation token.

When to rely on the organisation token

Prefer it for anything shared. Scheduled scans and pipeline runs should not depend on one person's credential, and one dedicated, read-only organisation token is easier to review and rotate than a spread of personal ones.

How do you rotate or remove a Git token?

Create the new token at your code host and paste it into Replace token. Click Save Git settings, then Verify, and only then revoke the old token at the code host. OWASP's Secrets Management Cheat Sheet says to rotate secrets regularly so that "any stolen credentials will only work for a short time". See key rotation.

To remove access entirely, click Clear token. Private repos then fail to clone until you save a new token. Clearing is also your first move if you suspect a leak. Follow it by revoking the token at its source (token revocation).

Where does your code go during a scan?

In a cloud scan, Cyberlop keeps the clone only while the scan runs. It deletes the clone once the scan ends, whether it completed, failed or was cancelled. Each scan runs in its own isolated, ephemeral container, and the repo mounts read-only. Relevant code excerpts go to your chosen AI provider over HTTPS; read AI provider settings for that side.

If your code must stay inside your network, a self-hosted agent sends no source out at all. See self-hosted scan agents and private scanning. The security page explains how Cyberlop handles stored credentials.

Troubleshooting Git access problems

Most clone problems trace back to the host, the token, the precedence or the URL, so work through the table in that order and stop at the first row that matches.

Common symptoms

Common mistakes

• Pasting a token with write access because it was already to hand.
• Leaving a former colleague's personal token saved on a shared workflow.
• Adding a host to Allowed hosts but forgetting to click Save Git settings.
• Using an SSH URL when creating the target. You cannot edit a target afterwards, so delete and recreate it, as add a target describes.

A note on scope

Only give Cyberlop code you own or have authority to test. Scope the token to the repos you intend to scan and no others.

Next step

With code access sorted, decide how the AI side is paid for and which models run each stage. Continue with AI provider settings.