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

Catch the bug in the pull request

CloudLens runs SAST on your first-party code with Opengrep and CloudLens rules — in the pull request and on push. Every finding is a file, a line and a data flow, with a suggested fix, so the bug is fixed before it merges.

Get a demoSee all code security
What you're watchinglive product
  1. 1
    Scan where the code is written

    Opengrep with CloudLens rules runs in the pull request and on push, so injection, auth and data-handling bugs are caught before merge.

  2. 2
    Follow the data flow

    CloudLens traces the tainted value from the request parameter to the query, so it is clear why the line is a finding, not just that it matched.

  3. 3
    Apply the suggested fix

    Each finding comes with a concrete fix, such as binding user input as a parameter instead of concatenating it into SQL.

  4. 4
    Make it a required check

    Promote a rule to a required PR check so the same class of bug cannot merge again.

Who does thisApplication security engineer, with the service's developersWhat you getInjection and data-handling bugs fixed in review, with the file, line, data flow and fix in one place.
In the PR
+ push
SAST runs where the code is written
Data flow
traced
from the request parameter to the sink
Fix
suggested
a concrete change, not just a match
Rules
tuned
CloudLens rules cut false positives

SAST that cries wolf gets turned off

Noisy scanners, findings without context, and a report that lands after the code already shipped.

Noise

Too many false positives

What usually happens: A generic linter flags hundreds of pattern matches, the team stops reading them, and the real injection bug hides in the noise.

How CloudLens resolves it: CloudLens rules are tuned for signal, and each finding shows the data flow so it is clear whether it is real.

Resolved
Timing

The report arrives after the merge

What usually happens: A nightly scan files a bug the morning after it shipped, when fixing it means another change and another review.

How CloudLens resolves it: SAST runs in the pull request and on push, so the finding lands while the author still has the code open.

Resolved
Context

A match is not an explanation

What usually happens: A finding says “tainted data” with no path, so the developer cannot tell a real bug from a safe pattern.

How CloudLens resolves it: CloudLens traces request parameter → concatenation → query, with the exact line and a parameterised fix.

Resolved

From the tainted line to a parameterised fix

Open the finding, read the tainted line, apply the suggested change — then file it with one click.

The tainted line, the data flow and the fix

Software Composition Analysis
Open a SAST finding and you see the vulnerable line, the path the tainted value takes from request to sink, and a concrete fix such as binding the input as a parameter. Create a Jira issue with it all attached.
  • The exact file and line
  • Request → sink data flow
  • A suggested, parameterised fix
SAST is one engine of four

See every risk in your repositories in one view

Explore code security

How an injection bug was fixed before it shipped

A Wednesday at Lumora Retail: a pull request on checkout-api trips the sql-injection rule in review.

MLMara LinAppSec engineer, Lumora Retail

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

    1
    Wed 14:10High

    A High SAST finding lands on the PR

    The pull-request check flags “SQL built from request input” at src/orders.ts:88 on checkout-api.
    2
    Wed 14:13

    Reads the data flow

    CloudLens traces req.query.status into a concatenated SQL string, so it is clearly a real injection, not a safe query.
    3
    Wed 14:20

    Applies the suggested fix

    The author switches to a parameterised query, binding status as $1, exactly as the finding suggests.
    4
    Wed 14:28SEC-114

    Files the trail and merges

    A Jira issue SEC-114 captures the file, line and fix; the re-run check passes and the PR merges clean.

SAST developers actually read

In the pull request

Findings land while the author still has the code open, so the fix is part of review, not a follow-up ticket.

Signal over noise

CloudLens rules are tuned to cut false positives, and the data flow makes it clear when a finding is real.

Straight to a ticket

One click opens a Jira issue with the file, line, data flow and suggested fix attached.

Software Composition Analysis Vulnerable and risky open-source dependencies.
Secret Scanning Keys and tokens in code, history and files.
Code Security Every risk in your repositories, in one view.

Static code analysis questions

Opengrep with CloudLens rules. It analyses your first-party code for injection, auth, cryptography and data-handling issues, and traces the data flow behind a finding.

In the pull request and on push, so a finding lands while the author still has the code open, rather than in a report the next morning.

Rules are tuned for signal, and every finding shows the data flow from source to sink, so a developer can confirm a real bug quickly and dismiss a safe pattern.

SAST finds the bug in the code and traces its data flow; it does not prove the path is reachable at runtime. Confirming reachability in a running workload is on the roadmap (Runtime Code Analysis).

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.