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

Bitbucket workspaces and every pull request, read for risk

Connect a workspace, project or repository access token. CloudLens scans each repository for secrets in code and history, insecure code, vulnerable packages, IaC and bitbucket-pipelines.yml, and checks every pull request the signed webhook sends it.

What you're watchinglive product
  1. 1
    #58 adds a Stripe live key

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

  2. 2
    The signed webhook reaches CloudLens

    pullrequest:created arrives with an HMAC signature; CloudLens scans the source branch.

  3. 3
    Policy fails, then passes

    The new secret fails the policy in CloudLens. The updated event after the fix commit rescans and passes.

Who does thisAppSec engineer and the developer who opened the changeWhat you getA secret is stopped at review instead of reaching main.
Read access tokensWrite scopes refused when Bitbucket reports them
Signed PR webhookCreated and updated · fork PRs refused
Git history tooSecrets still in old commits
Pipelines judgedStatic keys, unpinned images, install scripts

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: Bitbucket 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 Bitbucket

Paste a workspace, project or repository access token — or an Atlassian API token with your email.

Write scopes are refused when Bitbucket reports them · if it does not, CloudLens says it could not confirm read-only.

  • repository · read
  • pullrequest · read
  • repository:write · refused
  • repository:admin · refused
What you're watchinglive product
  1. 1
    Choose Bitbucket

    Workspace access token · Bitbucket Cloud.

  2. 2
    See exactly what is granted

    repository: Read · pullrequest: Read · repository:write: Refused · repository:admin: Refused.

  3. 3
    Repositories are found and scanned

    4 repositories in the lumora workspace 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 the CloudLens webhook (HMAC-signed) for pull request created and updated. CloudLens scans the source branch; 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.

  • webhook · pullrequest:created
  • New findings only
  • Pass / warn / fail policy
  • Verdict in CloudLens
What you're watchinglive product
  1. 1
    #58 adds a Stripe live key

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

  2. 2
    The signed webhook reaches CloudLens

    pullrequest:created arrives with an HMAC signature; CloudLens scans the source branch.

  3. 3
    Policy fails, then passes

    The new secret fails the policy in CloudLens. The updated event after the fix commit rescans and passes.

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

Bitbucket Pipelines, judged line by line

bitbucket-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.

  • image tag can change under you
  • package install runs lifecycle scripts
  • long-lived key in the pipeline file
What you're watchinglive product
  1. 1
    Open bitbucket-pipelines.yml

    3 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 · install script: package install runs lifecycle scripts.

  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 Bitbucket 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
bitbucket-pipelines.yml, judged by CloudLens rules
Repository posture
Partly
CODEOWNERS, fork policy, staleness, visibility · branch restrictions are admin-only, not assessed
Pull request scans
Yes
Signed webhook on created and updated · fork PRs are refused
Result in Bitbucket
Not today
Results stay in CloudLens
Pipeline → cloud
Partly
Role ARNs and long-lived keys detected · OIDC issuer not judged
Bitbucket Data Center
Not today
Bitbucket Cloud only

One week with Bitbucket 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:15Read-only

    Connects the lumora workspace

    A workspace access token with repository and pullrequest read. Bitbucket reports its scopes, so CloudLens confirms it is read-only.
    2
    Mon 11:20

    Adds the pull request webhook

    One HMAC-signed webhook for pull request created and updated. From then on every PR reaches CloudLens on its own.
    3
    Thu 16:40Critical

    Catches a key in the pipeline

    bitbucket-pipelines.yml exports a long-lived AWS secret key. CloudLens flags it Critical and maps the deploy-prod role it uses.
What is in your Bitbucket 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.

Bitbucket FAQ

Bitbucket Cloud. Bitbucket Data Center and Server are not supported today.

Workspace, project or repository access tokens, or an Atlassian API token with your email. App passwords are no longer offered by Bitbucket.

When Bitbucket reports the token's scopes, write scopes are refused. When it doesn't, CloudLens tells you it could not confirm read-only — and still only ever issues reads.

Not yet. Bitbucket shows branch restrictions only to repository admins, so CloudLens reports them as not assessed rather than guessing.

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.