Inside the security engine

If you are technical, you probably want to know what actually runs when you hit scan, and why you should trust the output. Sentrint is a vulnerability scanner for source code, and this is its architecture in plain terms. It has three layers: rule families that flag candidates, an AI review layer that filters them, and a scoring step that turns what survives into a report.

Layer one: six scanners, run in parallel

Layer one is not one tool. Six run over your repository at the same time, because no single one of them sees everything.

• Static analysis over your code and config. This is the SAST pass, and it is the biggest of the six: rule families for injection and cross-site scripting (SQL injection, command injection, path traversal, SSRF, XSS), insecure deserialization, mass assignment, missing input validation, weak password hashing, weak randomness, unverified JWT and webhook signatures, hardcoded secrets, secrets shipped to the browser through NEXT_PUBLIC_ or VITE_ variables, missing and client-side-only auth, exposed admin routes, open CORS, Supabase Row Level Security disabled or left permissive, public Supabase Storage buckets, open Firebase rules, soft-delete exposure, debug mode in production, committed .env files, over-broad AWS IAM in Terraform, and personal, Aadhaar, PAN and card data sitting in source or in log calls.
• Secret scanning over your git history. Up to three years of commits, looking for keys that were committed and later deleted. The file is clean; the history is not.
• Live secret verification over your files. Candidate secrets are confirmed against the provider before they are reported, so a finding means the credential was working at the moment of the scan rather than that it looked like a key.
• Two dependency scanners. Both your lockfiles and your manifests are matched against known vulnerability databases, and running two catches advisories that one of them has and the other does not yet.
• A cross-file Supabase check. It reads every migration under supabase/migrations/ and flags a table that gets created and never has Row Level Security enabled anywhere afterwards. That is a hole no single-file rule can see, because the mistake is the absence of a line rather than the presence of one.

The rules are written against the frameworks these apps are actually built in: Next.js on both the Pages and App Router, Express, Flask, FastAPI, Django, Mongoose and MongoDB, React, Vite, Supabase, Firebase and Terraform.

This layer is deliberately broad. The goal here is to catch everything that might be a problem, which means it also catches things that turn out not to be. That is what the next layer is for.

Layer two: the AI review layer filters false positives

A broad rule pass, on its own, produces noise. It flags a hardcoded string that looks like a secret but is a placeholder in a test. It flags a query that looks like injection but is safely parameterized a few lines up. If those reached your report unfiltered, you would spend your time sorting real from fake, which is exactly the work you came here to avoid.

So every flagged finding goes through an AI review layer before it reaches you. This layer reads each finding in context, the surrounding code and configuration, not just the line that tripped the rule, and decides whether it is a real, exploitable problem or a false alarm. A candidate that reads as a test fixture, a safe pattern, or a value that never touches untrusted input gets dropped. What survives is what held up under a second, context-aware look.

This is the layer that makes the report worth reading. A scanner that cries wolf trains you to ignore it. The point of the review layer is that when a finding reaches your report, it earned its place, so you can act on it instead of second-guessing it. If you fix what the report shows, you are fixing real holes, not chasing noise.

How much of this runs on a free scan

All of it. A free scan gets the same review layer, over the same findings, as a scan someone paid for. It used to be narrower on free, and that was the wrong trade: it made a free score read harsher than the paid scan of the same commit, which is a bad way to introduce yourself.

What is reviewed is decided by what is worth reviewing, not by what you paid. Dependency advisories are exact version matches that a model cannot improve on, so they are verified without AI. The review runs over your Critical and High code findings, on every plan.

One case where it still stops short, again on every plan: a repo with more than 150 Critical and High code findings skips the review entirely. A repo that noisy is going to grade badly whatever we discount, and every finding then keeps full weight. The report tells you when that happened to yours.

Two things it does not change:

• Every finding is shown to you either way. The review layer annotates findings, it never hides them.
• The README badge ignores the discount entirely. It is computed from raw severities, so a badge means the same thing on every plan.

The report tells you when this applies to your scan rather than leaving you to work it out.

Layer three: scoring by severity

What survives review gets scored. Each finding carries a severity: Critical, High, Medium, or Low. Critical and High are the holes that get apps broken into and the ones a determined attacker could use. Medium and Low are real but lower-risk or harder to exploit. The report sorts by severity so the worst is at the top, and it rolls the findings up into an overall score and a letter grade so you can see at a glance how the app is doing and watch that number move as you fix things.

Reading your report covers the score, the grade, and the severity levels from a user's point of view. Sentrint for developers goes deeper on the severity model and the rescan workflow.

Why the layers are split this way

The split is the whole design. Rules are good at breadth and bad at judgment. They can scan an entire repo for two dozen classes of hole in one pass, but they cannot tell a real secret from a placeholder, because that takes reading the surrounding context. Context-aware review is good at judgment and would be slow and expensive as the first pass over everything. So the rules go first and cast wide, the review layer goes second and reads what they caught, and only vetted findings get scored and shown. Breadth first, judgment second, and you see the result of both.

For the plain-English version of each hole these layers look for, see common vulnerabilities.

Run the engine on your app

The best way to understand the engine is to point it at your own code and read what comes back. Sign in with GitHub and scan a repo free, one a month, no card: start a scan.