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. This is the 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: rule families over code, config, and dependencies

The security engine runs many rule families across three surfaces: your application code, your configuration, and your dependency manifests. Each family targets a specific class of hole, and each surface catches problems the others cannot.

Over your code, the families look for injection and cross-site scripting (SQL injection, command injection, path traversal, SSRF, XSS), insecure deserialization, mass assignment and missing input validation, weak password hashing, weak randomness, and unverified JWT or webhook signatures. They look for leaked and hardcoded secrets, and for secrets that get shipped to the browser through public environment variables or tokens kept in local storage.

Over your configuration, the families check the settings that decide who can reach what: missing authentication and client-side-only auth, exposed admin pages, open CORS, row-level security disabled, open Firebase rules, soft-delete data exposure, debug mode left on in production, committed .env files, and over-broad cloud IAM in infrastructure config.

Over your dependency manifests, the engine matches the packages your app pulls in against known vulnerabilities, so a dependency shipping a documented, already-patched hole gets flagged with the version that fixes it.

This layer is deliberately broad. The goal at this stage 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

The review layer costs real money to run, so how much of it we run depends on your plan, and we would rather state that plainly than let you find out sideways.

On a paid scan we review up to 50 of your most severe findings. On a free scan we review 5.

This matters because of how scoring works. A finding the review layer marks as likely noise gets its weight discounted when we compute your score. A finding we never reviewed keeps its full weight, deliberately, because assuming an unreviewed finding is fine would be the dangerous direction to get wrong. The practical effect is that if a free scan turns up more than 5 Critical or High findings, your score can read a little harsher than a paid scan of the same commit would.

Two things this does not change. Every finding is shown to you either way, because the review layer annotates findings, it never hides them. And the README badge is computed from raw severities without any review discount at all, 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.