Sentrint for developers

If you write code, you already have opinions about security tools, mostly that they are noisy and slow. This page is the honest version of what Sentrint is, what it does well, and where it stops. It is an automated check for the classes of holes that AI builders and fast shipping tend to introduce. It is not a replacement for reading your own code.

The severity model

Every finding is scored Critical, High, Medium, or Low, and the report sorts by that order. Here is roughly what each level means in practice.

Critical is a hole that gets apps broken into, reachable and high-impact: a database anyone can read, a live key in the code, an admin page with no login. If a Critical is real, someone can hurt you with it today. Stop and fix these first.

High is a serious problem a determined attacker could use. Not always as immediate as a Critical, but not something you ship on purpose. Fix these right after the Criticals.

Medium is a real issue that is lower-risk or harder to exploit: a weakness that needs another condition to line up, or a smaller blast radius. Worth fixing, not worth blocking a release over on its own.

Low is minor or hygiene: good to clean up, not urgent, not going to be the thing that gets you breached.

The rule of thumb is simple. Clear Critical and High before you ship. Treat Medium and Low as backlog you burn down over time. The point of the ordering is that you do not have to triage severity yourself; the report already did, so top-to-bottom is the same as worst-first. Reading your report covers the score and grade that sit above these levels, and inside the security engine explains how a finding earns its severity in the first place.

The rescan workflow

A report is a snapshot. The way you prove a fix landed is to rescan and check the finding is gone.

The loop is: scan, read the finding, apply the fix, rescan the same repo. If the fix took, the finding drops out of the new report and your score moves up. If it is still there, the change did not land, and you go again. You are not trusting that a fix worked, you are confirming it against the same checks that flagged it.

Each finding ships with a fix prompt written for the AI builder that made your app, delivered in small steps so the tool changes one thing at a time instead of rewriting half your app. If you work in a code editor directly, the prompt still tells you exactly what the problem is and what the fixed shape looks like, so you can apply it by hand and rescan to confirm.

The security badge

Once your app is in good shape, you can show it. Sentrint gives you an embeddable security badge you can drop into your repo's README or your site. It is a small, honest signal that your code has been scanned, useful when you want to tell users, collaborators, or yourself that the app went through a security check rather than shipping unlooked-at.

The badge reflects real state, so keep it honest by keeping it current: fix, rescan, and let it show where the app actually stands.

You earn it at grade C. Below that the report shows the badge locked, with the grade it unlocks at on the button, because a D on a public README helps nobody.

If a repo that already earned its badge later slips below a C, the badge does not break and it does not start showing a failing grade. It falls back to a neutral "unrated" pill until the next scan brings you back to a C. Your README keeps working, and the incentive to get back above the line stays where it should be.

Where this fits alongside code review and CI

Be clear-eyed about scope. Sentrint is an automated check for a specific set of problems: the holes that AI builders and fast shipping tend to introduce, the classes covered in common vulnerabilities. It runs those rule families over your code, config, and dependencies, filters the results through a review layer, and hands you findings sorted by severity. That is a real, useful slice of your security posture, and it is the slice most likely to be wrong in an AI-built app.

It is not everything. It does not understand your business logic, so it will not catch an authorization bug that depends on your domain rules, a pricing flaw, or a workflow that leaks data through a path only you would recognize as sensitive. It does not replace a human reading the diff, and it does not replace the judgment a reviewer brings to intent and design.

The honest framing is that it sits next to code review and CI, not on top of them. Use it to catch the mechanical, well-known holes automatically and early, so human review can spend its attention on the things only a human can see. If you run CI, think of a scan as one more automated gate, the one aimed at the security classes that fast AI-assisted building tends to leave open. It closes the doors a machine can find. It does not excuse you from reading your own code.

Scan your repo

Point it at your code and see what the severity model, the rescan loop, and the badge look like on a real report. Sign in with GitHub and scan a repo free, one a month, no card: start a scan.