Aller au contenu
Créer un compte gratuit
Créer un compte gratuit

Quel niveau de sécurité offre Crunu ?

Nous concevons Crunu en partant du principe que son serveur sera attaqué. Voici, pour chaque attaquant prévu par le modèle de menaces du produit, ce qu’il obtient, ce qu’il n’obtient pas et quelle couche lui barre la route, y compris là où Crunu n’y peut rien.

Créer un compte gratuitLire le modèle de sécurité
  • AES-256-GCM chiffre chaque version
  • X25519 scelle les clés, Ed25519 signe
  • La clé du compte vient de votre mot de passe (PBKDF2-SHA256, 1 000 000 itérations) et d’une Secret Key d’environ 128 bits, et aucun des deux n’est envoyé au serveur
  • Aucune clé de déchiffrement sur le serveur, à aucune étape

Trois couches de protection, et des publications que vous pouvez vérifier

Le modèle de menaces de Crunu indique pour chaque défense la couche qui l’assure. Cela compte surtout quand l’attaquant est le serveur lui-même, car seules certaines couches continuent alors de fonctionner.

  • Cryptographie

    Qui détient la clé

    Les clés d’environnement ne sont scellées que pour les personnes, les machines et les jetons que vous autorisez, et les listes d’accès et les versions sont signées. Sans la clé, les données chiffrées restent chiffrées.

    Si quelqu’un prend le contrôle du serveurContinue de fonctionner.

  • Serveur

    À qui il remet les données chiffrées, et de qui il accepte les modifications

    Limites de connexion, expiration des sessions, règles réseau, délai d’attente du code de récupération, et coupure de l’accès d’une personne que vous avez retirée.

    Si quelqu’un prend le contrôle du serveurCesse de fonctionner.

  • Client

    Ce que vérifient votre navigateur et l’agent

    Signatures, numéros de version et empreintes : les appareils refusent tout ce qui n’est pas signé ou qui est plus ancien que ce qu’ils ont déjà vu. Masquer les valeurs à l’écran est aussi une règle du client : cela évite les accidents, pas la copie.

    Si quelqu’un prend le contrôle du serveurContinue de fonctionner, sauf si le serveur envoie une page web modifiée.

  • Publications vérifiables

    L’authenticité du code que vous exécutez

    Chaque publication de l’agent et de l’application web est signée avec Ed25519. Le build web est reproductible, et la page n’autorise aucun script tiers.

    Si quelqu’un prend le contrôle du serveurLes mises à jour de l’agent restent vérifiées. L’application web se vérifie elle-même à l’intérieur de la page qu’elle vérifie : elle ne peut donc pas repérer un serveur qui modifie les deux.

Exemple. Kiteline est une entreprise fictive.

Attaque par attaque

Une carte pour chaque attaquant du modèle de menaces de Crunu. Le verdict porte sur les valeurs de vos environnements ; tout ce que l’attaquant obtient d’autre est indiqué sur la carte.

  • ProtégéVos valeurs restent illisibles et intactes.
  • LimitéL’attaquant obtient quelque chose de concret, indiqué sur la carte.
  • Non protégéCrunu ne peut pas l’empêcher. La carte indique ce qui aide.

  1. Une copie de la base de données est divulguée

    Protégé

    Une sauvegarde divulguée, un disque volé, une intrusion dans un autre service ou un hébergeur de mauvaise foi.

    Ce qu’il obtient

    • Les données chiffrées de chaque environnement, les clés publiques et les enregistrements signés
    • Des métadonnées : les noms des projets et des environnements, qui fait partie de l’équipe et à quelle fréquence les choses changent
    • Les jetons, mais uniquement sous forme de hachages à clé (HMAC)

    Ce qu’il n’obtient pas

    • Vos valeurs : la copie ne contient aucune clé de déchiffrement
    • Un raccourci vers votre mot de passe : chaque tentative exige aussi votre Secret Key, qui n’a jamais été sur le serveur, et vérifier une seule tentative revient donc à explorer environ 2¹²⁸ possibilités
    • Des jetons utilisables : la clé de ces hachages n’est pas stockée dans la base de données

    Ne mettez pas de secrets dans les noms : un projet nommé d’après un accord pas encore annoncé révèle cet accord à quiconque lit la copie.

    Protégé parCryptographieServeur

  2. Quelqu’un prend le contrôle du serveur

    Limité

    Le contrôle de son code et de sa base de données : un intrus, un exploitant malveillant ou un compte cloud détourné. Sur app.crunu.com, c’est Crunu qui exploite ce serveur ; sur le vôtre, c’est vous.

    Ce qu’il obtient

    • Tout ce que contient une copie de la base de données, plus qui a téléchargé quelle version et quand
    • Le pouvoir de refuser le service ou de perdre vos modifications
    • La possibilité d’envoyer une page web modifiée qui capture votre mot de passe et votre Secret Key pendant que vous vous connectez. C’est le principal risque qui subsiste.

    Ce qu’il n’obtient pas

    • Une place parmi les destinataires : les clés d’environnement ne sont scellées que pour des clés certifiées par votre organisation, et vos appareils vérifient la liste d’accès signée
    • Une clé substituée ou des données modifiées : les clés sont fixées dans des enregistrements signés, et chaque version est signée et liée à son environnement et à son numéro
    • Un retour en arrière discret sur un appareil qui a vu des données plus récentes. Un appareil qui ne les a jamais vues ne peut pas s’en apercevoir.

    À chaque chargement, l’application se compare au manifeste signé de Crunu, et la page n’autorise aucun script tiers. Cette vérification s’exécute dans la même page : elle ne peut donc pas repérer un serveur qui modifie les deux.

    Protégé parCryptographieClient

  3. Quelqu’un intercepte la connexion

    Limité

    Un faux certificat TLS ou un proxy malveillant entre votre appareil et le serveur.

    Ce qu’il obtient

    • Ce que le serveur voit sur cette connexion : des données chiffrées et des métadonnées
    • La même possibilité qu’un serveur compromis d’envoyer une page web modifiée

    Ce qu’il n’obtient pas

    • Votre mot de passe ou votre Secret Key : aucun des deux ne transite sur le réseau, sous quelque forme que ce soit
    • Une connexion à rejouer : chaque signature de connexion mentionne l’adresse du serveur et une valeur à usage unique (nonce), elle ne fonctionne donc qu’une fois, et sur ce serveur uniquement

    Protégé parCryptographieClient

  4. Un collègue part en mauvais termes

    Limité

    Une personne que vous avez retirée de l’organisation et qui a gardé tout ce qu’elle pouvait.

    Ce qu’il obtient

    • Tout ce qu’elle a vu avant d’être retirée. Ces valeurs continuent de fonctionner chez vos fournisseurs jusqu’à ce que vous les réémettiez.

    Ce qu’il n’obtient pas

    • Quoi que ce soit de plus de la part du serveur : il cesse aussitôt de lui servir des données
    • Les nouvelles versions : chaque clé d’environnement qu’elle détenait est renouvelée, ses anciennes clés n’ouvrent donc rien de nouveau, même avec des données chiffrées volées

    Le rapport d’exposition montre quelles versions la personne a reçues, et la liste de contrôle de réémission indique les valeurs à changer chez chaque fournisseur.

    Protégé parServeurCryptographie

  5. Un collègue regarde au-delà de son rôle

    Protégé

    Un membre honnête mais curieux : un développeur qui a accès à development, ou un Operator qui configure les machines.

    Ce qu’il obtient

    • Les environnements qui lui ont été accordés, qu’il peut copier. Masquer les valeurs dans l’application est un choix d’affichage, pas du chiffrement.

    Ce qu’il n’obtient pas

    • L’environnement production, avec un accès à development : il n’en a pas la clé
    • La moindre valeur en tant qu’Operator : un Operator ne détient aucune clé d’environnement
    • D’autres fichiers avec le rôle Specific files : il ne reçoit une copie scellée que des fichiers choisis

    Protégé parCryptographie

  6. Un jeton de session est volé

    Limité

    Copié depuis la mémoire du navigateur ou dans le journal d’un proxy.

    Ce qu’il obtient

    • Ce que le serveur autorise à ce compte jusqu’à la fin de la session : après 12 heures d’inactivité, ou 7 jours au plus

    Ce qu’il n’obtient pas

    • Vos valeurs : les déchiffrer exige des clés que le jeton ne contient pas
    • Des modifications signées : une liste d’accès ou une version exige votre clé de signature
    • Le contrôle de votre compte : changer votre mot de passe ou votre Secret Key exige les deux

    Votre compte liste chaque appareil et chaque session, et vous pouvez mettre fin à l’une d’elles ou à toutes.

    Protégé parServeurCryptographie

  7. Votre ordinateur portable est volé

    Limité

    Un appareil sur lequel vous vous êtes connecté, volé avec l’application ouverte ou verrouillée.

    Ce qu’il obtient

    • Votre Secret Key, que le navigateur conserve par défaut : seul votre mot de passe fait alors barrière
    • Ce qui est ouvert, jusqu’à ce que l’application se verrouille après 10 minutes d’inactivité (réglage par défaut)

    Ce qu’il n’obtient pas

    • Vos clés une fois l’application verrouillée : elles restent chiffrées sans votre mot de passe
    • Votre compte : une session ouverte ne peut changer ni votre mot de passe, ni votre Secret Key, ni les clés de votre compte

    Depuis un autre appareil, retirez l’appareil volé ou utilisez « Device compromised » : cette action remplace les clés de votre compte et renouvelle les clés de tous les environnements dont vous déteniez une clé.

    Protégé parCryptographieServeur

  8. Quelqu’un obtient les droits root sur une machine avec l’agent

    Limité

    Un serveur sur lequel tourne l’agent crunu est un destinataire légitime, tout comme quiconque le contrôle.

    Ce qu’il obtient

    • Tout ce qui a été livré à cette machine. Un programme déjà en cours d’exécution garde ses variables jusqu’à son redémarrage.

    Ce qu’il n’obtient pas

    • D’autres machines ou d’autres environnements : chaque machine a ses propres clés et ne reçoit que ce qui lui a été accordé
    • Un accès durable : un bail prend fin après 24 heures sans contact, et une machine révoquée efface ses environnements en quelques minutes tant qu’elle est en ligne

    Protégé parCryptographieServeur

  9. Un code d’enrôlement est divulgué

    Protégé

    Le code à usage unique que vous donnez à crunu enroll sur une nouvelle machine.

    Ce qu’il obtient

    • Une chance d’enrôler sa propre machine, s’il utilise le code avant votre machine

    Ce qu’il n’obtient pas

    • L’approbation : un administrateur n’approuve une machine qu’après avoir comparé l’empreinte que crunu enroll affiche sur la vraie
    • Une seconde tentative discrète : le code est valable 15 minutes par défaut et brûlé dès sa première utilisation, et un code réutilisé déclenche une alerte

    Protégé parCryptographieServeur

  10. Un jeton CI est divulgué

    Limité

    Un jeton de service copié depuis le stockage de secrets d’un pipeline.

    Ce qu’il obtient

    • Exactement ce qui a été accordé au jeton, souvent un seul environnement, jusqu’à ce que vous le révoquiez ou qu’il expire

    Ce qu’il n’obtient pas

    • Un autre environnement : la clé de production n’est jamais scellée pour un jeton auquel production n’a pas été accordé
    • Une connexion depuis ailleurs, si le jeton est lié par OIDC : sans le jeton de votre fournisseur CI pour le bon dépôt et la bonne branche, il n’entre pas

    Protégé parCryptographieServeur

  11. Quelqu’un essaie de deviner des mots de passe sur le serveur

    Protégé

    Des tentatives de connexion depuis une seule adresse ou réparties sur de nombreuses adresses.

    Ce qu’il obtient

    • 10 tentatives échouées par adresse IP et 5 par compte toutes les 15 minutes

    Ce qu’il n’obtient pas

    • Un indice qu’un compte existe : une adresse e-mail inconnue et un mauvais mot de passe obtiennent la même réponse
    • Une entrée avec le seul mot de passe : la connexion exige aussi votre Secret Key, et un nouvel appareil exige votre second facteur une fois celui-ci activé
    • Un raccourci par les codes et les liens : ils contiennent au moins 128 bits aléatoires et sont stockés sous forme de hachages à clé

    Protégé parServeurCryptographie

  12. Quelqu’un modifie une publication de l’agent

    Protégé

    Un binaire crunu ou un script d’installation modifié.

    Ce qu’il obtient

    • Un moyen d’entrer, seulement s’il contrôle aussi l’application web qui affiche votre commande d’installation, comme lors d’une prise de contrôle du serveur

    Ce qu’il n’obtient pas

    • Une installation discrète : la commande d’installation de l’application web contient les sommes de contrôle SHA-256 du manifeste de publication, et l’application web vérifie la signature Ed25519 de ce manifeste
    • Une mise à jour discrète : crunu self-update vérifie la signature de la publication avec une clé intégrée à l’agent

    Protégé parCryptographieClient

  13. Un logiciel malveillant s’exécute sur votre appareil

    Non protégé

    Un enregistreur de frappe, une extension de navigateur malveillante ou quelqu’un qui a les droits root sur votre ordinateur.

    Ce qu’il obtient

    • Votre mot de passe et votre Secret Key pendant que vous les tapez, et tout ce que cet appareil déchiffre

    Ce qu’il n’obtient pas

    • Les environnements que votre compte ne peut pas ouvrir

    Aucun chiffrement ne peut protéger un appareil contre lui-même. Utilisez des appareils que vous contrôlez et, après une compromission, utilisez « Device compromised » depuis un appareil sain et réémettez les valeurs auxquelles il avait accès.

    Protégé parAucune couche de Crunu

Toutes les limites connues, et que faire face à chacune

La cryptographie

Des briques standard dans deux implémentations : WebCrypto, intégré au navigateur, et la bibliothèque standard de Go dans l’agent. Les deux sont testées avec les mêmes vecteurs de test partagés.

La cryptographie
AlgorithmeSon rôle dans CrunuOù il s’exécute
AES-256-GCMChiffre chaque version d’un environnement. Des données authentifiées additionnelles (AAD) lient les données chiffrées à leur organisation, à leur environnement et à leur numéro de version : on ne peut pas les faire passer pour d’autres.Navigateur et agent
X25519Scelle une clé d’environnement pour un destinataire : une personne, une machine ou un jeton de service. Chaque copie scellée utilise une nouvelle paire de clés.Navigateur et agent
Ed25519Signe les listes d’accès, les versions, les liens de partage et les publications. Les appareils vérifient chaque signature avant de faire confiance à un enregistrement.Navigateur et agent ; Crunu signe les publications
HKDF-SHA256Dérive d’un seul secret une clé distincte pour chaque usage, pour qu’aucune clé ne serve à deux fins.Navigateur, agent et serveur
PBKDF2-SHA256, 1 000 000 itérations, et la Secret KeyTransforme votre mot de passe en une moitié de la clé de votre compte. Votre Secret Key, environ 128 bits aléatoires, en est l’autre moitié. Aucun des deux ne quitte votre appareil.Votre navigateur, ou crunu dans le terminal
SHA-256Relie les entrées du journal d’audit en une chaîne de hachage, et produit des empreintes de clés que vous pouvez comparer à l’œil.Le serveur écrit la chaîne ; votre navigateur et vos propres outils peuvent la recalculer
Remplissage jusqu’à 4 096 octetsArrondit chaque version chiffrée à un nombre entier de blocs de 4 Ko, pour que sa taille exacte ne se voie pas.Navigateur et agent, avant le chiffrement
  • Une clé pour chaque environnement. L’accès à development n’ouvre rien dans production. Chaque personne, chaque machine et chaque jeton reçoit sa propre copie scellée des seules clés auxquelles il a droit.
  • Chaque format indique sa version. Chaque enregistrement indique la version de son format ("v": 2), et la dérivation de clé a la sienne (kdf.v). Les appareils refusent les versions qu’ils ne connaissent pas : le serveur ne peut donc ni réduire le coût d’une tentative pour deviner votre mot de passe, ni glisser un format plus ancien.

Les ordinateurs quantiques

Un ordinateur quantique assez puissant casserait certaines de ces briques et en affaiblirait à peine d’autres. Aucun ordinateur de ce type n’existe aujourd’hui. Voici où en est Crunu, sans prédire quand un tel ordinateur pourrait apparaître.

Les ordinateurs quantiques
AlgorithmeAttaque quantiqueCe que cela signifierait pour Crunu
AES-256-GCMAlgorithme de Grover : une recherche plus rapide de la cléIl reste environ 128 bits de robustesse. Le NIST s’attend à ce qu’AES-256 reste sûr pendant très longtemps.
SHA-256 et HMACRecherche de type GroverUne large marge subsiste pour la chaîne de hachage du journal d’audit et pour les hachages à clé. Le NIST utilise SHA-256 comme référence pour ses niveaux de sécurité post-quantique.
PBKDF2 et la Secret KeyRecherche de type Grover ; l’algorithme de Shor ne s’applique pasDeviner exige toujours les 128 bits aléatoires de la Secret Key, la taille d’une clé AES-128, qui selon le NIST devrait rester sûre pendant des décennies. Ni le mot de passe ni la Secret Key n’atteignent le serveur.
X25519Algorithme de Shor : la clé privée à partir de la clé publiqueCassé. Les clés d’environnement scellées avec lui pourraient être ouvertes.
Ed25519Algorithme de ShorCassé. Des signatures pourraient être falsifiées, mais seulement au moment d’une attaque. Les données passées ne sont pas exposées.

Récolter maintenant, déchiffrer plus tard

Chaque clé d’environnement est scellée pour les clés publiques X25519 de ses destinataires, et les copies scellées sont stockées sur le serveur à côté de ces clés publiques. Quelqu’un qui conserve une copie de la base de données pourrait, une fois qu’un ordinateur quantique assez puissant existera, ouvrir ces copies scellées et lire les versions enregistrées dans cette copie de la base. Le NIST appelle cette menace « harvest now, decrypt later » (récolter maintenant, déchiffrer plus tard).

Elle ne touche que ce que contient cette copie. Les versions enregistrées après qu’elle a été prise n’y figurent pas, et un identifiant que vous avez réémis chez son fournisseur ne vaut plus rien pour qui déchiffre l’ancien.

Votre mot de passe, votre Secret Key et la clé de votre compte ne sont pas exposés de cette façon : ils n’atteignent jamais le serveur, et seules des fonctions symétriques leur sont appliquées. L’attaque n’en a d’ailleurs pas besoin, puisqu’elle vise directement les clés X25519.

Les signatures

Les signatures Ed25519 protègent les listes d’accès, les versions et les publications. Un ordinateur quantique permettrait d’en falsifier de nouvelles, mais une falsification ne compte qu’au moment où elle est créée et acceptée : c’est donc un risque pour le jour où un tel ordinateur existera, pas pour les données enregistrées aujourd’hui. Le NIST fait la même remarque : les signatures ne sont pas exposées à la menace « récolter maintenant, déchiffrer plus tard ».

Ce que Crunu utilise aujourd’hui, et la suite

Crunu n’utilise pas d’algorithmes post-quantiques aujourd’hui. Le NIST a publié ses premières normes post-quantiques en août 2024 : ML-KEM pour l’établissement de clés (FIPS 203) et ML-DSA pour les signatures (FIPS 204). Son plan de transition, finalisé en octobre 2026, range l’accord de clés sur courbes elliptiques et EdDSA parmi les algorithmes qu’il déclarera obsolètes après 2030 et interdira dans les normes du NIST après 2035.

Le passage à la cryptographie post-quantique figure dans la feuille de route de Crunu. Nous n’annonçons pas d’algorithmes ni de dates sur lesquels nous ne pouvons pas encore nous engager : quand la cryptographie de Crunu changera, cette page le dira.

Ce que vous pouvez faire dès maintenant

  • Demandez-vous combien de temps chaque secret garde sa valeur. Une clé que vous réémettez tous les quelques mois perd peu face à une copie déchiffrée des années plus tard ; un identifiant racine à longue durée de vie perd davantage.
  • Réémettez régulièrement les valeurs à longue durée de vie chez leurs fournisseurs, et enregistrez chaque nouvelle valeur comme une nouvelle version.
  • Si une copie de la base de données entre d’autres mains vous préoccupe, hébergez votre propre serveur. La base de données et ses sauvegardes restent alors chez vous.

Sources

  1. NIST: NIST Releases First 3 Finalized Post-Quantum Encryption Standards (August 13, 2024)
  2. NIST FIPS 203: Module-Lattice-Based Key-Encapsulation Mechanism Standard (August 2024)
  3. NIST FIPS 204: Module-Lattice-Based Digital Signature Standard (August 2024)
  4. NIST IR 8547: Transition to Post-Quantum Cryptography Standards (October 2026)
  5. NIST: Post-Quantum Cryptography FAQs (AES and Grover’s algorithm)
  6. L. K. Grover: A fast quantum mechanical algorithm for database search (1996)
  7. P. W. Shor: Polynomial-Time Algorithms for Prime Factorization and Discrete Logarithms on a Quantum Computer (1997)

Vérifié le 28 octobre 2026.

Vérifiez par vous-même

Nous n’avons encore ni badges ni certificats à montrer. Voici ce que vous pouvez vérifier dès aujourd’hui, et ce qui manque.

  • Des publications signées.Chaque publication de l’agent et de l’application web est signée avec une clé de publication Ed25519. crunu self-update vérifie la signature avec une clé intégrée à l’agent, et l’application web affiche « Signed build » une fois qu’elle s’est vérifiée par rapport au manifeste signé.
  • Un build web reproductible.Un même commit source produit toujours les mêmes fichiers, octet pour octet. Le code source n’est pas publié : aujourd’hui, seul Crunu peut donc reconstruire une publication et comparer.
  • Aucun script tiers.La politique de sécurité du contenu (CSP) de la page n’autorise que le code de Crunu, qu’elle charge avec des sommes de contrôle d’intégrité (SRI).
  • Peu de dépendances.L’agent n’utilise que la bibliothèque standard de Go, et le code du navigateur ne comprend qu’un seul paquet npm, yaml.
  • Un journal d’audit vérifiable hors de Crunu.Les propriétaires et les administrateurs peuvent exporter le journal en JSONL et recalculer sa chaîne de hachage SHA-256 avec leurs propres outils.
  • Ce qui manque.Aucun audit de sécurité externe, aucune certification SOC 2 ou ISO 27001, et aucun code source publié. Crunu est en accès anticipé ; la section Audits et documents liste les documents dont nous disposons.
  • Vous avez trouvé un problème ?Écrivez à security@crunu.com. Le même contact figure dans notre fichier security.txt, et la page Limites connues liste toutes les limites que nous connaissons déjà.
Exemple. Kiteline est une entreprise fictive.

Questions sur la sécurité de Crunu

Crunu peut-il lire mes secrets ?

Non. Le serveur, exploité par Crunu sur app.crunu.com ou par vous sur le vôtre, ne stocke que des données chiffrées et n’a aucune clé capable de les déchiffrer. Il voit en revanche des métadonnées : les noms, les adresses e-mail, le journal d’audit et le moment où chaque version a été enregistrée. Pour atteindre vos valeurs, il faudrait modifier le code qui s’exécute sur votre appareil, par exemple au moyen d’une page web modifiée : c’est le principal risque qui subsiste parmi ceux décrits sur cette page.

Que se passe-t-il si le serveur de Crunu est piraté ?

Qui s’y introduit obtient des données chiffrées, des clés publiques, des hachages à clé des jetons et des métadonnées. Il ne peut ni déchiffrer vos valeurs, ni s’ajouter à une liste d’accès, ni modifier une version sans que vos appareils s’en aperçoivent. Il peut cesser de vous servir ou envoyer une page web modifiée. Si app.crunu.com subit une intrusion, nous préviendrons par e-mail les titulaires des comptes concernés dans les meilleurs délais.

Et si j’oublie mon mot de passe ?

Personne ne peut le réinitialiser, nous compris, car nous ne recevons jamais votre mot de passe ni votre Secret Key. Votre Emergency Kit imprimé et un code de récupération sont les moyens de revenir dans votre compte. Si vous les perdez tous, votre compte ne peut plus être ouvert, mais les propriétaires et les administrateurs peuvent toujours ouvrir les environnements partagés de l’organisation.

Crunu protège-t-il contre les ordinateurs quantiques ?

En partie. AES-256 et SHA-256 devraient tenir. X25519 et Ed25519 tomberaient face à un ordinateur quantique assez puissant, qui n’existe pas aujourd’hui. Crunu n’utilise pas d’algorithmes post-quantiques aujourd’hui : une copie de la base de données conservée pendant des années pourrait donc un jour exposer les versions qu’elle contient. Le passage à la cryptographie post-quantique figure dans la feuille de route de Crunu.

Crunu a-t-il été audité ?

Non. Crunu est en accès anticipé, n’a pas de certification SOC 2 ou ISO 27001, et aucun audit de sécurité externe n’a été publié. Son code source n’est pas publié non plus. Ce que vous pouvez vérifier aujourd’hui figure plus haut, dans « Vérifiez par vous-même ».

Héberger mon propre serveur est-il plus sûr qu’app.crunu.com ?

Cela change la personne à qui vous faites confiance, pas le chiffrement. Votre propre serveur garde la base de données et ses sauvegardes chez vous et envoie la page web depuis une infrastructure que vous contrôlez. En contrepartie, les sauvegardes, les mises à jour et le secret propre au serveur deviennent votre affaire. Le serveur est disponible sur demande à support@crunu.com.

Comment signaler une vulnérabilité ?

Écrivez à security@crunu.com en indiquant les étapes pour la reproduire, et ne mettez aucun vrai secret dans votre signalement. Le même contact figure dans notre fichier security.txt, et la page Modèle de sécurité indique les règles à respecter pendant vos tests.

Gardez les secrets de votre équipe sur un serveur qui ne peut pas les lire

Créez votre compte sur app.crunu.com. Vos clés sont créées dans votre navigateur, et le serveur ne reçoit que des données chiffrées.

Gratuit pendant l’accès anticipé. Lire le modèle de sécurité