New Savings Proposals: approve, test and roll back cost changesLearn more Sign in|Talk to a cloud engineer
Product tourGet a demo

Your GitLab group, scanned end to end — even self-managed

Connect a group access token with read_api and read_repository. CloudLens reads every project in the group and its subgroups — secrets in code and git history, insecure code, dependencies, IaC and .gitlab-ci.yml — and scans any merge request on demand.

Get a demoAll integrations
What you're watchinglive product
  1. 1
    An MR adds a Stripe live key

    !87 on payments-service adds a hard-coded key.

  2. 2
    Scan merge request !87

    From CloudLens, enter the MR number. The head is scanned and compared with main by fingerprint.

  3. 3
    The verdict stays in CloudLens

    The policy fails the new secret. After the fix commit, Rescan shows it passing.

Who does thisAppSec engineer and the developer who opened the changeWhat you getA secret is stopped at review instead of reaching main.
Read scopes onlyread_api + read_repository; write scopes refused
gitlab.com or self-managedAny https GitLab host
Git history tooSecrets still in old commits
.gitlab-ci.yml judgedStatic keys, curl | sh, deploys on MRs

Code risk ships long before anyone looks

A secret, a vulnerable package or a risky workflow is cheapest to fix in review, and most expensive once it is in production.

Secrets

Deleted is not gone

What usually happens: A developer removes a cloud key from the code. It stays in git history, readable by anyone who can clone the repository.

How CloudLens resolves it: Gitleaks reads the last 2,000 commits too, so the key is found, rotated and purged.

Resolved
Review

Reviewers miss what scanners catch

What usually happens: A pull request adds a live payment key in a config file. Two approvals later, it is on main.

How CloudLens resolves it: The MR is scanned and fails your policy in CloudLens while it is still in review.

Resolved
Pipelines

CI has production access

What usually happens: GitLab CI holds long-lived cloud keys or an over-trusting role, and nobody connects it to what it can change.

How CloudLens resolves it: Every pipeline file is judged line by line, and its role or key is traced to the AWS resources it can reach.

Resolved

Read-only, set up once in GitLab

Paste a group access token (or a personal access token) for the group CloudLens should read.

Write scopes are refused at connect time · the token is stored sealed (AES-GCM).

  • read_api · read
  • read_repository · read
  • api · refused
  • write_repository · refused
What you're watchinglive product
  1. 1
    Choose GitLab

    Group access token · gitlab.com or your self-managed GitLab.

  2. 2
    See exactly what is granted

    read_api: Read · read_repository: Read · api: Refused · write_repository: Refused.

  3. 3
    Repositories are found and scanned

    5 repositories in the lumora-retail group and its subgroups start their first scan.

Who does thisAdmin connecting the source in CloudLens SettingsWhat you getCloudLens can read the code, and nothing else.

Secrets, code, packages, IaC and CI — in one pass

Every repository is scanned by Gitleaks (current files and git history), Opengrep running CloudLens's own rules, and Trivy for dependencies, SBOM, licences and IaC.

Each finding carries its evidence and the fix. Send it to Jira, Slack or Microsoft Teams in one click.

  • Secrets + history
  • SAST
  • SCA + SBOM
  • IaC + Dockerfiles
  • CI/CD config
What you're watchinglive product
  1. 1
    Four engines run on each repository

    Results are grouped into secrets, code, dependencies, IaC and CI/CD.

  2. 2
    A key that was deleted, but not gone

    A cloud access key removed six weeks ago is still in commit 4f2a91c.

  3. 3
    Fix it, and track it

    Three steps to rotate and purge it, and SEC-91 opened in Jira from the finding.

Who does thisAppSec engineer triaging the first scanWhat you getThe riskiest finding is ticketed with its evidence on day one.

Every merge request, checked against your policy

Merge requests are scanned on demand: enter the MR number in CloudLens. Results and the policy verdict stay in CloudLens.

The MR head is scanned in full and compared with the default branch by fingerprint, so only new findings count. Your policy passes, warns or fails on new secrets, vulnerabilities, code findings and misconfigurations.

  • Scan by MR number
  • New findings only
  • Pass / warn / fail policy
  • Verdict in CloudLens
What you're watchinglive product
  1. 1
    An MR adds a Stripe live key

    !87 on payments-service adds a hard-coded key.

  2. 2
    Scan merge request !87

    From CloudLens, enter the MR number. The head is scanned and compared with main by fingerprint.

  3. 3
    The verdict stays in CloudLens

    The policy fails the new secret. After the fix commit, Rescan shows it passing.

Who does thisDeveloper and reviewer on the changeWhat you getNew risk is caught at review, not after release.

GitLab CI, judged line by line

.gitlab-ci.yml is parsed as text — never executed — and every risky line is flagged with its rule and severity.

The roles a pipeline assumes are matched to your AWS roles, and their OIDC trust is judged. So you see what a compromised pipeline could change in production.

  • image tag can change under you
  • long-lived key in the pipeline file
  • remote script piped to a shell
  • secret written to the job log
  • production deploy runs for merge requests
What you're watchinglive product
  1. 1
    Open .gitlab-ci.yml

    5 lines are flagged as the file is read.

  2. 2
    Each line gets a rule and severity

    unpinned image: image tag can change under you · static cloud key: long-lived key in the pipeline file.

  3. 3
    Traced to the cloud

    The deploy-prod role leads to the checkout-api service and orders-db in prod-core.

Who does thisPlatform engineer who owns the pipelinesWhat you getPipeline risk is ranked by what it can reach in production.

What CloudLens reads in GitLab today

Straight from the product. Where something is not assessed, we say so rather than imply it.

Capability
Status
Details
Secrets in current files
Yes
Gitleaks, on every scan
Secrets in git history
Yes
Last 2,000 commits within 365 days
Insecure code (SAST)
Yes
Opengrep running 31 CloudLens rules
Vulnerable dependencies, SBOM, licences
Yes
Trivy; licence findings when your org sets a licence policy
Reachability
Partly
Import-level, for npm and Python
IaC and Dockerfiles
Yes
Trivy config checks
CI/CD config
Yes
.gitlab-ci.yml, judged by CloudLens rules
Repository posture
Partly
Most controls · deploy keys, webhooks and outside members not assessed
Merge request scans
Partly
On demand by MR number · no automatic webhook yet
Result in GitLab
Not today
Results stay in CloudLens
Pipeline → cloud
Yes
Role ARNs matched to AWS roles; GitLab OIDC trust judged
Self-managed GitLab
Yes
Any https GitLab host
Group settings (2FA, SSO)
Not today
Not assessed

One week with GitLab connected

Lumora Retail is a fictional company. The steps are how CloudLens behaves.

SOSam OkaforAppSec engineer, Lumora Retail

Lumora Retail is a fictional company. The people, names and numbers are sample data.

    1
    Mon 09:10Read-only

    Connects the lumora-retail group

    A group access token with read_api and read_repository. CloudLens refuses a token with api or write_repository.
    2
    Mon 10:00Critical

    Finds static keys in CI

    .gitlab-ci.yml in platform/infra sets AWS_ACCESS_KEY_ID in variables and deploys on merge request events. Both are flagged Critical and High.
    3
    Wed 15:30

    Scans !87 before review

    Sam scans the merge request by number. A new Stripe live key fails the policy; the author moves it to the secret manager.
What is in your GitLab history?

Scan your repositories with read-only access

Get a demo

The rest of your code and CI

GitHub

GitHub App · github.com

Learn more

Bitbucket

Workspace access token · Bitbucket Cloud

Learn more

Azure DevOps

Personal access token · dev.azure.com

Learn more

Jenkins

Through your code host · Any repository CloudLens scans

Learn more

Read-only

CloudLens never pushes, comments or merges. On GitHub, the one write is a check run, and only if you grant Checks: write.

History included

Secrets are looked for in the last 2,000 commits within a year, not just today's files.

Code to cloud

Container images, Terraform and pipeline roles are matched to the AWS resources they run as or deploy.

One finding list

Code findings sit next to cloud findings in Atlas, with the same Jira, Slack and Teams actions.

GitLab FAQ

A group access token or a personal access token with read_api and read_repository. Tokens with write scopes are refused, and the token is stored sealed.

Yes. Enter your GitLab's https address when you connect.

Not yet. Scan any merge request by number from CloudLens; the result and the policy verdict are shown there.

No. Results stay in CloudLens, and you can send a finding to Jira, Slack or Teams in one click.

Ready to see CloudLens in action?

Connect a read-only AWS role or Azure service principal. We'll walk you through your bill, your security graph and the first things worth fixing.