Sécurité et conformité

Cette page décrit les mesures de sécurité techniques mises en œuvre par Scanyze pour protéger vos données. Elle est destinée à être fournie à un auditeur externe ou à un RSSI qui évalue la plateforme.

Résidence des données

Aucune donnée tenant ne quitte le Canada par défaut. Le seul chemin où des données peuvent être traitées hors-Canada est l'opt-in explicite vers Claude Premium pour les analyses (voir GPU vs Premium).

Isolation multi-tenant — Row-Level Security

Principe

Toutes les tables sensibles utilisent PostgreSQL Row-Level Security (RLS). Avant chaque requête, le backend Go positionne le paramètre de session :

SET app.current_tenant_id = '<uuid-du-tenant>';

Chaque table contient une politique RLS du type :

CREATE POLICY tenant_isolation ON targets
USING (tenant_id = current_setting('app.current_tenant_id')::UUID);

Conséquence : PostgreSQL refuse physiquement de retourner une ligne d'un autre tenant, même si une faille applicative tente de bypasser le filtre côté Go.

Tables protégées

Toutes les tables contenant des données client sont sous RLS. Liste non exhaustive :

targets, scans, findings, code_repositories, code_scans, code_issues, code_scan_ai_report_artifacts, code_issue_ai_analyses, agents, agent_events, legal_compliance_scans, dark_web_breaches, darkweb_provider_configs, darkweb_query_log, cloud_connectors, cloud_findings, cloud_secrets, pentests, pentest_authorizations, chatbot_tests, reports, notifications, subscriptions, invoices, ai_credits, ai_credit_history, ai_usage, api_keys, webhooks, audit_logs.

Tests d'isolation

L'équipe Scanyze exécute en CI un test d'isolation RLS qui vérifie qu'un tenant ne peut lire/écrire aucune donnée d'un autre tenant via 100+ scénarios. Voir secuscan-api/internal/repository/postgres/_test.go.

Chiffrement

En transit

• TLS 1.3 (TLS 1.2 minimum) sur toutes les communications publiques (api.scanyze.com, app.scanyze.com)
• Certificats Let's Encrypt + DNS-01 challenge, renouvellement auto
• HSTS activé avec max-age=31536000 + preload
• Politiques de cipher conformes Mozilla Modern (TLS 1.3 only sur les flux internes)

Au repos

Tous les secrets en DB sont chiffrés via AES-256-GCM avec une master key gérée par OVH KMS, dérivée par tenant. La clé n'est jamais exposée à l'application — le déchiffrement se fait via API KMS au moment de l'utilisation.

Authentification et autorisation

Authentification

• Mots de passe : bcrypt cost 14, politique stricte (12+ caractères, complexité, HIBP check).
• MFA TOTP : disponible (Google Authenticator, Authy, 1Password).
• MFA SMS : disponible si numéro de téléphone configuré (Telnyx).
• SSO Zitadel : OIDC, plan Enterprise.
• JWT : access token TTL 60 min, refresh token TTL 7 jours.
• API keys : format sk_live_xxx, hashées en DB, scopes granulaires.
• Sessions : stockées en DB, révocables individuellement, persistance contrôlée.

Autorisation

• Rôles : superadmin, tenant_admin, tenant_user, tenant_viewer, msp_partner.
• RBAC : permissions par endpoint et par scope (ex. targets:read, scans:write).
• RLS : isolation par tenant au niveau DB (couche supplémentaire).
• Workspaces : restriction supplémentaire au niveau workspace pour les utilisateurs non-admin.

Audit

Toutes les actions sensibles sont tracées dans audit_logs :

• Connexions / déconnexions / changements de mot de passe
• Création / modification / suppression de cibles, scans, repos
• Lancements de scans / pentests
• Modifications de configuration (settings, branding, billing)
• Achat de top-ups
• Actions admin (gestion d'utilisateurs, modification de rôles)
• MSP act_as_tenant : impersonation par un MSP loggée en msp_act_as_tenant (visibilité totale pour le client final)
• Suppressions de données (request d'export, request de suppression de compte)

Champs : actor_user_id, actor_email, tenant_id, action, resource_type, resource_id, ip_address, user_agent, details (JSONB), timestamp.

Rétention :

• Plan Free / Essentiel : 30 jours
• Starter : 90 jours
• Pro : 365 jours
• Business : 730 jours
• Enterprise : configurable jusqu'à 7 ans

Sécurité applicative

Validation d'entrées

Toutes les entrées utilisateur sont validées via go-playground/validator (côté Go) et Zod (côté Next.js). Les requêtes JSON malformées sont rejetées en 400.

Protection SQL injection

100% des requêtes DB utilisent des requêtes paramétrisées (driver pgx avec $1, $2, ...). Aucune concaténation de string SQL n'est tolérée — un test CI échoue si du code introduit fmt.Sprintf dans du SQL.

Protection CSRF

Cookies SameSite=Strict + token CSRF dans le header X-CSRF-Token pour les requêtes mutantes depuis le frontend.

Protection XSS

• Frontend Next.js : tout rendu utilisateur passe par React (escape automatique). Pas de dangerouslySetInnerHTML sauf cas validés en review.
• Headers : Content-Security-Policy strict, X-Content-Type-Options: nosniff, X-Frame-Options: DENY.

Rate limiting

• Limites par tenant et par endpoint (voir API REST)
• Burst control via Redis
• Auth endpoint : 5 tentatives login / 15 min / IP, puis lockout exponential backoff

Sandbox des workers

Les workers de scan (network, code, pentest, cloud, chatbot) tournent dans des pods Kubernetes isolés :

• Filesystem read-only sauf /tmp (limité à 1 GB)
• Network policies restrictives — accès uniquement au DB, Redis, S3, et aux cibles externes autorisées
• Aucun accès SSH ou exec depuis l'extérieur
• UID non-root (UID 991)
• Resource limits strictes (CPU, memory, ephemeral storage)
• Cleanup automatique : à la fin du job, le pod est détruit (pas de réutilisation)

Gestion des secrets

Côté SecuAAS

• Secrets K8s gérés via secuops + OVH KMS
• Aucun secret dans le code source
• Rotation manuelle annuelle pour les API keys externes (Anthropic, OpenAI, Telnyx, Resend, Stripe)
• Rotation automatique tous les 90 jours pour les internal secrets (DB password, JWT signing key)

Côté tenant

• Les secrets que vous fournissez (PAT Git, secrets webhook, identifiants cloud, API keys dark web) sont chiffrés AES-256-GCM avec une master key dérivée par tenant.
• Les secrets ne sont jamais loggés en clair (filtres au niveau du logger zerolog).
• Les secrets ne quittent jamais le data center sauf pour leur usage légitime (ex. PAT GitHub utilisé uniquement pour cloner le repo).

Backups et continuité

• Base PostgreSQL : backup OVH Managed quotidien (rétention 30 jours), point-in-time recovery 7 jours.
• Object Storage : versioning activé, soft-delete 30 jours.
• K8s manifests : versionnés dans Forgejo, restaurables à tout moment via secuops deploy.
• DR drill : test annuel de restauration complète (RTO objectif < 4h, RPO < 24h).

Conformité réglementaire

Loi 25 (Québec) — Loi modernisant des dispositions législatives en matière de protection des renseignements personnels

PIPEDA (Canada)

10 principes équitables couverts. Consultez la politique de confidentialité publique pour la mise en correspondance détaillée.

RGPD (UE)

• DPA disponible sur demande (legal@secuaas.com)
• Sous-traitants documentés (OVH, Anthropic si Claude opt-in, Resend, Telnyx, SecuCFO)
• Mécanisme de base légale : exécution du contrat (Art. 6.1.b)
• Transferts internationaux : SCC ('22) pour Anthropic uniquement (opt-in)

SOC 2 Type 2

Audit prévu Q4 2026 (cabinet ext. canadien). Trust Services Criteria couverts : Security, Availability, Confidentiality, Privacy.

ISO 27001:2022

Plateforme alignée sur les 93 contrôles Annex A. Certification prévue Q1 2027.

Tests de sécurité réguliers

• Scans Scanyze sur Scanyze : nous mangeons notre propre dogfood — un scan EASM complet de *.scanyze.com tourne chaque nuit.
• Pentest annuel externe : confié à un cabinet québécois indépendant (résultats partagés sur demande sous NDA).
• CI/CD security checks : Semgrep + gosec + govulncheck + Trivy SCA + Hadolint sur chaque PR.
• Code review obligatoire : aucun merge sans review. Le /security-review est exécuté avant chaque commit.
• Bug bounty : programme privé invite-only via HackerOne.

Contact sécurité

Pour signaler une vulnérabilité ou poser une question de sécurité :

• Courriel : security@scanyze.com
• PGP : empreinte de la clé publique disponible sur scanyze.com/.well-known/security.txt
• SLA : accusé de réception sous 24h, triage sous 72h, fix sous 30 jours pour critical/high

Nous ne poursuivons pas les chercheurs en sécurité qui agissent de bonne foi. Voir notre security.txt (RFC 9116).

Sources de cette page

• Politique RLS : 173 migrations dans secuscan-api/internal/migrations/
• Audit : secuscan-api/internal/api/handlers/admin_audit.go
• KMS : intégration OVH KMS via secuscan-api/internal/services/kms/

À jour pour Scanyze v0.130.x.