Your code and your data

The short version

You are handing us read access to your code. You should know precisely what happens to it. This page is the precise answer, and it matches what the privacy policy says. If a claim here ever disagrees with the privacy policy, the privacy policy is the one that governs.

The headline fact: your source code is never stored. It is fetched into a single scan job, scanned, and discarded when that job exits. There is no copy kept, no backup, and nothing is trained on it. The findings stay. The code does not.

What does a scan actually read?

When you sign in with GitHub we ask for read access, and read access is all it is. It does two things: it lists your repositories so you can pick one, and it reads the one you picked. No pushes, no pull requests, and no reading repos you did not choose. The token that grants it is encrypted, and it is deleted with your account.

The scan itself runs in an isolated, single-use job. Your code is read there, the engine checks it, and when the job exits the code is gone. How a scan works walks through that job step by step, and inside the security engine covers what it reads once it is in there.

One deliberate limit on the output. A finding will point at the file and line where a leaked secret lives, but it never prints the secret in full. A report should not become a second leak.

What do you keep, and for how long?

We hold as little as the product can run on. This is the whole list, and it is the same list the privacy policy publishes, so the two can never drift apart.

• Your GitHub profile, meaning your id, username, email and avatar. This is who your account is. Kept until you delete the account.
• Your GitHub token, encrypted, used only to list your repositories and read the one you pick. Deleted with the account.
• Your repository. Cloned into an isolated scan job, scanned, then deleted when the job exits. It is never written to our database at any point.
• Code around a finding. Up to ten lines either side of a Critical or High finding in your own code, saved so your fix prompt can be rebuilt after the scan files are gone. Never taken from a finding that exposed a secret, so a leaked credential is never written down. Deleted after 30 days.
• Scans and findings, meaning your reports, scores and the fix prompts we generated for them. Kept until you delete them.
• Payment records, meaning an amount and a date. We never see your card. Retained because tax law requires it.
• Support messages, kept so we can answer you and keep the thread, and unlinked from you when you delete the account.

The row worth reading twice is the fourth one. It is the only code that outlives a scan, it is capped at ten lines either side, and it is gone in thirty days whether you delete anything or not.

Do you use cookies?

One signed session cookie keeps you signed in. That is it. No advertising cookies, no tracking cookies.

Who else touches your data?

A few outside services help run Sentrint, our payment provider handling billing as merchant of record among them. The current list, and what each one does, lives on the privacy policy rather than being repeated here, so there is one source that never goes stale.

Your rights are real routes, not promises

Under India's Digital Personal Data Protection framework, and for every customer wherever you are, you have rights over your data. These are not marketing lines. They are actual features in the product.

You can export every record we hold. You can correct it. You can erase it, which removes your account and the data tied to it. And there is a grievance channel with a named person on it.

The grievance officer is Gourab Dasgupta, reachable at [email protected]. A grievance is acknowledged within 2 to 3 business days and resolved within 30 days.

Export and erase are available to you directly in Settings. No email, no waiting, no support ticket. Export hands you every record we hold. Erase removes your account and the data tied to it, subject only to the payment records that tax law requires us to retain.

The reasoning behind all of this

The design goal is simple. The more of your data we hold, the more there is to leak, and the more you have to trust us about. So we hold as little as the product can function on, we never write your repository to our database, and we make the exits one click. Strict rules built into the product beat a promise on a page.

There is an honest limitation worth stating. One developer builds Sentrint. There is no large security team behind it and no compliance badge, at least not yet. What there is instead is a short, strict set of rules, built into how the product works rather than written on a page, and a one-click way out if you ever want it. The person who wrote these rules is the same one who answers your support email.

Try it

You can read all of this before you ever sign in. When you are ready, scan a repo free, one a month, no card: start a scan.