Sécurité

Dernière mise à jour : 25 avril 2026

Zarev est encore jeune. On préfère être transparent sur l'état actuel plutôt que vendre une sécurité qu'on n'a pas encore validée par un tiers.

Audit externe

Un audit Aikido (ou équivalent SAST + DAST + dependency scanning) est planifié post-launch Pro, dès que la base d'utilisateurs justifie l'investissement. La mention sera mise à jour ici dès que l'audit est terminé.

Bug bounty informel

On n'a pas encore de programme bug bounty payant. Si tu trouves une vulnérabilité, on t'invite à nous la signaler à security@zarev.dev. En échange : remerciement public dans le hall of fame ci-dessous (si tu le souhaites), et un accès Pro gratuit à vie.

Politique de divulgation responsable

On suit un cycle classique de divulgation responsable :

Accusé de réception sous 72h.
Fix vulnérabilité critique sous 14 jours (RCE, auth bypass, data leak).
Fix vulnérabilité haute sous 30 jours (XSS, IDOR avec impact limité).
Divulgation publique 90 jours après fix, ou sur ta demande explicite.

Contrôles de sécurité actifs

Mesures techniques en place aujourd'hui :

Gitleaks pre-strip côté CLI (~150 patterns) avant tout envoi backend.
Row Level Security (RLS) sur toutes les tables Supabase contenant des données utilisateur. Service role isolé du flux user.
Journal d'audit local côté CLI (~/.zarev/audit.log) — chaque scan/brief est tracé.
Tous les secrets (clés API, tokens) chargés via variables d'environnement uniquement. Aucun secret committé.
Sentry actif côté frontend et backend avec scrubber strict sur PII (emails, tokens, project_description).
TLS 1.3 obligatoire pour toute communication CLI ↔ backend. Rejet des certificats invalides.

Repo et SECURITY.md

Le pipeline backend Zarev (nom interne : Pulse) est partiellement public. Le SECURITY.md du repo contient les détails techniques pour reporter une vulnérabilité : github.com/Arch-s-Technologies/pulse/blob/master/SECURITY.md.

Hall of fame

Personne pour l'instant. Sois le premier.