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

Every GitHub repository, read for risk before it ships

Install the read-only CloudLens GitHub App. CloudLens scans every repository for secrets — even in git history — insecure code, vulnerable packages, IaC and GitHub Actions, then checks each pull request against your policy and traces deploy workflows to the AWS roles they assume.

Get a demoAll integrations
What you're watchinglive product
  1. 1
    Sam opens #412 with a Stripe live key

    The diff adds a hard-coded sk_live key to payments/config.py.

  2. 2
    CloudLens scans the pull request head

    The new secret fails the org policy. The CloudLens code scan check run fails with one annotation.

  3. 3
    Merging is blocked, then unblocked

    Because the check is required, #412 can't merge. Sam moves the key to the secret manager and the check passes.

Who does thisAppSec engineer and the developer who opened the changeWhat you getA secret is stopped at review instead of reaching main.
Read-only GitHub AppMetadata, contents, administration, actions — read
Git history tooSecrets removed from code but still in commits
Pull request checksA failing check run blocks the merge, if you make it required
Code to cloudWorkflows traced to AWS roles; OIDC trust judged

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 CloudLens check fails on the new secret, and a required check blocks the merge.

Resolved
Pipelines

CI has production access

What usually happens: GitHub Actions 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 GitHub

Install the CloudLens GitHub App on your organization and pick the repositories it may read.

Read-only App · each scan gets a one-repo, contents:read token that is revoked after use.

  • Metadata · read
  • Contents · read
  • Administration · read
  • Actions · read
  • Checks · not requested
What you're watchinglive product
  1. 1
    Choose GitHub

    GitHub App · github.com.

  2. 2
    See exactly what is granted

    Metadata: Read · Contents: Read · Administration: Read · Actions: Read · Checks: Not requested.

  3. 3
    Repositories are found and scanned

    5 repositories in the lumora-retail organization 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, with zizmor for GitHub Actions.

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.

A failing check, right on the pull request

Automatic scans need Pull requests: read and the pull_request event added to the App. The check run is posted when you grant Checks: write; make it a required check to block the merge.

The PR 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.

  • pull_request event
  • New findings only
  • Pass / warn / fail policy
  • Check run + annotations
What you're watchinglive product
  1. 1
    Sam opens #412 with a Stripe live key

    The diff adds a hard-coded sk_live key to payments/config.py.

  2. 2
    CloudLens scans the pull request head

    The new secret fails the org policy. The CloudLens code scan check run fails with one annotation.

  3. 3
    Merging is blocked, then unblocked

    Because the check is required, #412 can't merge. Sam moves the key to the secret manager and the check passes.

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

GitHub Actions, judged line by line

.github/workflows/deploy.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.

  • pull_request_target runs fork code with secrets
  • every job gets a write token
  • action not pinned to a commit SHA
  • PR title expanded into a shell command
What you're watchinglive product
  1. 1
    Open .github/workflows/deploy.yml

    4 lines are flagged as the file is read.

  2. 2
    Each line gets a rule and severity

    dangerous-triggers: pull_request_target runs fork code with secrets · excessive-permissions: every job gets a write token.

  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 GitHub 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
.github/workflows, judged by zizmor plus CloudLens rules
Repository posture
Yes
Branch protection, required reviews, CODEOWNERS, visibility and more · webhooks not assessed
Pull request scans
Yes
pull_request event, or scan any PR by number
Result in GitHub
Partly
Check run with annotations when you grant Checks: write
Pipeline → cloud
Yes
Workflow role ARNs matched to AWS roles; OIDC trust judged
GitHub Enterprise Server
Not today
github.com only today
Organization settings (2FA, SSO)
Not today
Not assessed

One week with GitHub 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

    Installs the App on lumora-retail

    Sam installs the CloudLens GitHub App with read-only permissions and picks 5 repositories. The first scan starts straight away.
    2
    Mon 09:40Critical

    Finds a key nobody knew about

    Gitleaks finds a cloud access key in payments-service's history: removed from the code six weeks ago, still in commit 4f2a91c. Sam opens SEC-91 in Jira from the finding.
    3
    Tue 14:20

    Fixes the deploy workflow

    deploy.yml uses pull_request_target and an unpinned action, and the deploy-prod role's OIDC trust has no sub condition. Platform pins the action and scopes the trust to main.
    4
    Thu 11:05Blocked

    Blocks a new secret at review

    #412 adds a Stripe live key. The required CloudLens check fails, the merge is blocked, and the fix lands the same afternoon.
What is in your GitHub history?

Scan your repositories with read-only access

Get a demo

The rest of your code and CI

GitLab

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

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.

GitHub FAQ

Metadata, contents, administration and actions, all read. Each scan uses a token narrowed to one repository with contents: read, and revokes it afterwards.

Yes, once you add Pull requests: read and the pull_request event to the App. You can also scan any pull request by number from CloudLens.

CloudLens posts a check run when you grant Checks: write. Make that check required in branch protection and a failing scan blocks the merge. CloudLens does not comment on pull requests.

Not today. The App works with github.com organizations.

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.