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

Every risk in your code, in one view

Connect GitHub, GitLab, Bitbucket or Azure DevOps read-only. CloudLens scans your repositories for vulnerable dependencies, insecure code, risky infrastructure-as-code and committed secrets — in the pull request and on every push — and routes each finding to the team that owns it.

Get a demoConnect a code host
What you're watchinglive product
  1. 1
    One view, five kinds of finding

    Secrets, insecure code (SAST), vulnerable dependencies (SCA), IaC misconfigurations and CI/CD risks all land in one Code findings table.

  2. 2
    Four engines, read-only

    Gitleaks for secrets, Opengrep for first-party code, Trivy for dependencies and IaC, plus CI/CD rules — over a read-only connection.

  3. 3
    Open any finding

    The finding shows where it is, why it matters and how to fix it. The Critical secret here is a key still sitting in git history.

  4. 4
    File it with one click

    Create a Jira issue with evidence and fix steps, or post to Slack or Teams, routed to the repository's owner.

Who does thisSecurity engineer, with the teams that own each repositoryWhat you getOne prioritised backlog of code risk, with evidence and an owner on every finding.
4
0
engines: Gitleaks, Opengrep, Trivy and CI/CD rules
5
0
finding types: secrets, code, dependencies, IaC, CI/CD
In the PR
+ on push
scanned, so risk is caught before it merges
Read-only
always
a read token; CloudLens never writes to your code

Code risk is split across four tools

A secret scanner, a SAST tool, a dependency scanner and an IaC linter — four backlogs, four owners, no shared priority.

One view

Four scanners, four backlogs

What usually happens: Secrets, SAST, SCA and IaC findings live in separate tools, so nobody can say what the top code risk is this week.

How CloudLens resolves it: Every finding lands in one table with a shared severity, so the Critical secret outranks a low-severity lint everywhere.

Resolved
In the flow

Risk is found after it ships

What usually happens: Scans run on a schedule, so a vulnerable dependency or a leaked key is noticed days after it reached the main branch.

How CloudLens resolves it: The same engines run in the pull request and on push, so risk is caught before it merges.

Resolved
Read-only

Security tools ask for write access

What usually happens: Many code scanners want write scopes to a repo, which security teams are reluctant to grant.

How CloudLens resolves it: CloudLens connects with a read-only token and never writes to your code — it opens issues in your tracker instead.

Resolved

Open a finding, see the evidence

Every finding is a file, a line and a fix plan, with one click to a ticket.

Secrets, code, dependencies and IaC — ranked together

See how a code host connects
Four engines scan your repositories read-only. Each finding carries a severity, the repository, the exact location and a fix plan. Open it to see the full detail and file a Jira issue with evidence attached.
  • Gitleaks · Opengrep · Trivy · CI/CD rules
  • Severity, repository, file and line on every finding
  • One click to Jira, Slack or Teams
Four engines, one connection

Connect a code host read-only in minutes

See the integrations

What CloudLens scans in your code

Software Composition Analysis

Vulnerable and risky open-source dependencies, with the CVE, the fixed version and the import path.

Static Code Analysis (SAST)

Insecure first-party code — injection, auth and data-handling bugs — with the file, the line and a suggested fix.

IaC Security

Misconfigurations in Terraform, CloudFormation and Kubernetes manifests, caught before they are applied.

Secret Scanning

Keys and tokens in code, the full git history and config files, with masked evidence only.

Software Composition Analysis Vulnerable and risky open-source dependencies.
Static Code Analysis SAST on your first-party code, in the pull request.
IaC Security Terraform, CloudFormation and Kubernetes manifests.
Secret Scanning Keys and tokens in code, history and files.

How the top code risk got an owner before standup

A Monday at Lumora Retail: four engines finish a scan and the Critical finding rises to the top of one backlog.

DPDev PatelSecurity engineer, Lumora Retail

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

    1
    Mon 09:0288 open

    The scan lands in one table

    Secrets, SAST, SCA and IaC findings all appear in Code findings, sorted by severity across 14 repositories.
    2
    Mon 09:06

    Opens the Critical

    A cloud access key still in checkout-api's git history, with the commit and a masked preview.
    3
    Mon 09:12

    Reviews the High findings

    A SQL-injection in orders-api and a log4j-core CVE in catalog-sync, each with the file and the fixed version.
    4
    Mon 09:18SEC-91

    Files the top risk

    The secret becomes Jira issue SEC-91 with evidence and fix steps, routed to the Checkout team.

Code security questions

GitHub, GitLab (cloud and self-managed), Bitbucket and Azure DevOps, plus Jenkinsfile analysis. Each connects with a read-only token or app.

Gitleaks for secrets (including git history), Opengrep for first-party code, and Trivy for dependencies and infrastructure-as-code, with additional CI/CD rules.

Yes. The same engines run in the pull request and on every push, so risky code is caught before it reaches the default branch.

No. It connects read-only and never writes to your code. Findings are turned into issues in your own tracker, such as Jira, which you choose to create.

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.