What access we ask for

Connecting a repository uses a standard, read-only OAuth permission through GitHub or GitLab: the same category of access you'd grant a linting tool or a CI service. We never ask for write access to your code, and we can't push, edit, or delete anything in your repository.

What we actually read

We don't read your source code line by line the way a person would. Our scanning step extracts a list of the components and libraries your project depends on (its dependency manifest), not your business logic or proprietary algorithms. That list, not your raw code, is what gets checked against public vulnerability databases.

What we store

We store the component inventory, scan results, alert history, and any report drafts generated for your account. We do not store a full copy of your source code, and we do not retain it beyond the scan needed to build that inventory.

Who can see it

Your account data is only accessible to your own team members and, for support purposes, a small number of people on ours, under the same confidentiality obligations as any vendor with access to your infrastructure. We don't sell data, and we don't use your specific code to train any model shared with other customers.

Encryption and infrastructure

Data is encrypted in transit and at rest. Infrastructure details, subprocessors, and our approach to incident response will be published here in full before general availability, alongside our completed security questionnaire for procurement teams that need one.

CRA Alert is pre-launch. The practices above describe our intended architecture and are being finalized ahead of the September 2026 launch. If you have specific security requirements (SOC 2, a signed DPA, a security questionnaire), let us know on the call and we'll prioritize getting you what you need.

Why not just run Syft and Grype yourself?

You can, and if you already have the engineering time to build and maintain that pipeline, you may not need us. What CRA Alert adds is the parts around the scan: a live 24h/72h countdown the moment something is flagged as actively exploited (not just "vulnerable"), a report already drafted in the format the reporting process expects, and a history you can point to later. For a team where nobody owns this full-time, that's the part that's easy to build once and then forget to maintain.

Questions before you connect anything?

Book a call and ask us directly.

Book a call