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

Azure Repos and Pipelines, scanned with one read token

Connect a personal access token with Code (Read). CloudLens scans every repository in your Azure DevOps organization — secrets in code and history, insecure code, dependencies, IaC and azure-pipelines.yml — and checks each pull request the service hook sends it.

What you're watchinglive product
  1. 1
    !1204 adds a Stripe live key

    A pull request on Retail/payments-service adds a hard-coded key.

  2. 2
    The service hook reaches CloudLens

    git.pullrequest.created arrives with its secret; CloudLens scans the pull request.

  3. 3
    The verdict is in CloudLens

    The new secret fails the policy. After the fix, the updated event rescans and it passes.

Who does thisAppSec engineer and the developer who opened the changeWhat you getA secret is stopped at review instead of reaching main.
Code (Read) PATFull-access tokens are refused
PR service hookCreated and updated · fork PRs refused
Branch policiesAssessed per repository
Pipelines judgedcurl | bash, printed secrets, static keys

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 PR is scanned and fails your policy in CloudLens while it is still in review.

Resolved
Pipelines

CI has production access

What usually happens: Azure Pipelines 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 Azure DevOps

Create a PAT with Code (Read) for your Azure DevOps organization and paste it in.

Full-access tokens are refused · CloudLens only ever issues reads with the token you give it.

  • Code (Read) · read
  • Full access · refused
What you're watchinglive product
  1. 1
    Choose Azure DevOps

    Personal access token · dev.azure.com.

  2. 2
    See exactly what is granted

    Code (Read): Read · Full access: Refused.

  3. 3
    Repositories are found and scanned

    4 repositories in the lumora 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.

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 pull request, checked against your policy

Add a CloudLens service hook for pull request created and updated (basic-auth secret). Results and the verdict stay in CloudLens.

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.

  • service hook · git.pullrequest.created
  • New findings only
  • Pass / warn / fail policy
  • Verdict in CloudLens
What you're watchinglive product
  1. 1
    !1204 adds a Stripe live key

    A pull request on Retail/payments-service adds a hard-coded key.

  2. 2
    The service hook reaches CloudLens

    git.pullrequest.created arrives with its secret; CloudLens scans the pull request.

  3. 3
    The verdict is in CloudLens

    The new secret fails the policy. After the fix, the updated event rescans and it passes.

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

Azure Pipelines, judged line by line

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

The roles and long-lived keys a pipeline uses are matched to your AWS inventory. So you see what a compromised pipeline could change in production.

  • remote script piped to a shell
  • secret variable written to the log
  • long-lived key in the pipeline
What you're watchinglive product
  1. 1
    Open azure-pipelines.yml

    3 lines are flagged as the file is read.

  2. 2
    Each line gets a rule and severity

    curl | bash: remote script piped to a shell · secret printed: secret variable written to the log.

  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 Azure DevOps 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
azure-pipelines.yml, judged by CloudLens rules
Repository posture
Partly
Branch policies · bypass, force-push, delete and signing need permissions a Code (Read) token cannot read
Pull request scans
Yes
Service hook on created and updated · fork PRs are refused
Result in Azure DevOps
Not today
Results stay in CloudLens
Scheduled rescans
Partly
Weekly
Azure DevOps Server
Not today
dev.azure.com only

One week with Azure DevOps 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:20Read-only

    Connects the lumora organization

    A PAT with Code (Read) only. CloudLens refuses a full-access PAT.
    2
    Mon 10:05High

    Finds secrets printed in a pipeline

    azure-pipelines.yml echoes SqlAdminPassword into the build log and sets a long-lived AWS key. Both are flagged.
    3
    Tue 12:30

    Adds the service hook

    Pull request created and updated now reach CloudLens. The next PR with a live key fails the policy before review.
What is in your Azure DevOps history?

Scan your repositories with read-only access

The rest of your code and CI

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.

Azure DevOps FAQ

Azure DevOps Services at dev.azure.com. Azure DevOps Server is not supported today.

A personal access token with Code (Read). Full-access tokens are refused. Azure DevOps can't show whether a token is Read or Read & write, so create it with Read only — CloudLens only ever issues reads.

Weekly, plus every pull request the service hook sends.

Branch policies. Settings behind the Security API — bypass, force-push, delete and signing — need more than Code (Read), so they are reported as not assessed.

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.