Moolé · Code Scanning (SAST) · flaws that are actually reachable

01 · The problem

Working code and safe code are not the same thing.

Ask a coding assistant for an endpoint and it reaches for the shortest path that runs. Here it fetches an invoice by id with no ownership check. The code works. It also lets any logged-in user read anyone else's invoice. That is broken access control, and it looks completely normal on the page.

invoices.pywritten by a coding assistant · unguarded

# GET /invoices/{invoice_id} def get_invoice(invoice_id, current_user): invoice = db.query(Invoice).filter( Invoice.id == invoice_id # no owner check ).first() return invoice # any user reads any invoice

Every scanner on the market can flag a pattern like this. The trouble is the ten thousand other lines it flags on the same run that no attacker can ever reach. That is the noise your team learns to ignore, and it is where the one real issue hides.

02 · It traces the real path

From where input enters to where it turns dangerous.

Old SAST matches patterns line by line. Moolé is execution-aware. It follows untrusted input from the request that carries it, across functions and files, all the way to the spot where it becomes a query or a shell call. A finding only fires when a real path exists from that source to that sink.

source · untrusted

request param

?id= from the caller

step

handler()

passes it along, unchecked

step

build_query()

glues it into a string

sink · dangerous

db.execute()

runs it against the database

A finding fires only when the input actually travels the whole way. Real path, real finding.

03 · Verdict, side by side

The same line. Two very different answers.

A pattern scanner sees a risky-looking query and flags it, with no idea whether anything reaches it. Moolé proves the path first, then decides. When the tainted input really does arrive at the sink, it blocks the merge and shows the fix.

◍ pattern scanner flag, no context

# it sees a string query query = f"SELECT * FROM invoices WHERE id = {invoice_id}" ! flagged: possible sql injection no idea if input reaches it lands in a pile of 1,000 alerts

◍ Moolé path proven

# traced source to sink tainted input reaches sink: yes → real finding, blocked on PR # the fix it opens query = "SELECT * FROM invoices" " WHERE id = %s AND owner_id = %s" db.execute(query, (invoice_id, user.id)) ✓ parameterized · ownership enforced

04 · Built for pull requests

It reviews the change, not the whole history.

Moolé runs on the diff. It looks at the code you just wrote, in the pull request, while it is still cheap to fix. No re-litigating a decade of legacy code your team was never going to touch this sprint. That is most of where the 70% of noise goes.

01

Scan the PR diff

It reads the changed code, not the entire codebase. Fast, focused, and free of legacy noise nobody is fixing today.

Changed lines in, verdict on the PR out.

02

Trace real data flows

Execution-aware analysis follows untrusted input across functions and files to the sink, instead of matching patterns in place.

Source to sink, or it does not fire.

03

Prioritize by exploitability

Findings are ranked by whether an attacker can actually reach them, so the short list at the top is the list worth fixing.

Reachable first. Theoretical last.

04

Block risky merges

Set the bar per repo. Real, reachable findings stop the merge. Everything below the line keeps velocity moving.

Custom thresholds, no blanket gate.

05

Automated remediation PRs

When there is a clean fix, Moolé opens it as a pull request: the parameterized query, the ownership filter, ready to review.

The fix arrives with the finding.

06

Noise cut in week one

Teams see SAST noise drop by 70% in the first week, without turning a single rule off. Nothing is silenced, the real work just rises to the top.

70% less noise. Zero rules disabled.

Old SAST flags a pattern.
Moolé proves a path.