Security

How we handle your code and data

We built a security scanner, it would be a strange business to run loosely with your data. Here's exactly how your code and results are handled, in plain English, and what we do and do not claim about our own security.

Your code is never stored

When you upload a zip, it's extracted into a temporary, isolated sandbox to run the scan. That sandbox and the uploaded file are both deleted immediately after the scan finishes, whether it succeeds, fails, or errors out partway through. We don't keep a copy of your source code anywhere, ever.

AI explanations, not AI training

The plain-English explanations in your report are generated by sending the specific finding (and a small surrounding code snippet, where relevant) to Claude. That's the only use: generating your report. Your code is never used to train or fine-tune any model, and this is a contractual commitment from our AI provider, not just a policy statement.

Secrets are redacted before they ever leave your scan

When our secret scanner finds something like an exposed API key, the actual secret value is redacted before it's stored or sent anywhere else in our pipeline, including to the AI model that writes the explanation. We tell you where the problem is, not what the secret was.

Database-level access control, not just app-level checks

Your scans, findings, and reports are scoped to your account using Row Level Security at the database layer, the same class of protection our own Supabase RLS checker looks for in your project. A bug in our application code isn't enough on its own to expose another user's data.

Least-privilege service & personnel access

The background worker that runs your scan uses a scoped, server-only service credential, it's never exposed to the browser, and it's used only for what's necessary to run scans and write results. Access to production data by Riskline personnel is restricted to what's needed to operate and support the Service, isn't granted by default, and isn't unlimited even for the people who built the platform.

Encryption

Data in transit between your browser, our application, and our infrastructure is encrypted using TLS. Data at rest is encrypted using our infrastructure providers' standard encryption for data stored on their platforms (including our database and storage provider). We don't claim a specific third-party encryption certification beyond what our providers themselves publish.

Backups

Our database infrastructure relies on our provider's standard backup and redundancy practices. We don't offer a guaranteed recovery-time or recovery-point commitment, and we recommend exporting or saving any report you consider important rather than relying on Riskline as your only copy.

Your Trust Badge reveals a grade, not your findings

If you choose to embed a Riskline badge on your own site, it only shows your letter grade and a short summary. It never reveals your raw findings, file paths, or any code. Sharing it is entirely your choice, and the badge reflects the state of your project at the time of the scan it links to, not a live or ongoing guarantee.

Payments never touch our servers

Billing is handled directly by Lemon Squeezy, our merchant of record. We never see or store your card number, only a customer ID and your subscription status.

What we don't claim

We take security seriously and design the Service with the practices above, but no online service is completely secure, and we don't claim otherwise. Riskline is provided on an "AS-IS" basis as described in our Terms of Service, we don't hold a SOC 2, ISO 27001, or similar third-party security certification as of this writing, and a scan or grade is not a guarantee that a project is free of vulnerabilities. If that changes, we'll update this page rather than let marketing claims outrun what we can actually back up.

Found a vulnerability in Riskline itself?

We welcome good-faith security research into our own Service. If you find an issue, report it privately to support@riskline.co with enough detail to reproduce it, and give us a reasonable window to investigate and fix it before any public disclosure. Please don't access, modify, or exfiltrate another user's data while investigating. See our Terms of Service for the full policy.

If something goes wrong

If we ever experience a data breach, our notification commitments (including timelines to regulators and to affected users) are set out in our Privacy Policy. This page is a description of our safeguards, not a promise that a breach cannot happen.

Questions about any of this? Reach us at support@riskline.co.