Divulgation responsable

Portée

Cette politique couvre les actifs que nous exploitons nous-mêmes.

• groupitcs.ca et ses sous-domaines;
• virementfrauduleux.com;
• la fonction serveur qui reçoit les formulaires du site.

Ce que cette politique ne couvre pas

Les systèmes de nos clients ne relèvent pas de cette politique, même lorsque nous y intervenons dans le cadre d'un mandat. Un test sur ces systèmes exige l'autorisation écrite de leur propriétaire.

Comment nous signaler une faille

Écrivez à [email protected] en indiquant l'actif visé, la description de la faille, les étapes de reproduction, l'impact que vous estimez et, si possible, une capture ou une trace. Le français et l'anglais sont acceptés.

Si vous souhaitez un canal chiffré, demandez-le dans un premier message sans détail technique, nous vous en ouvrons un.

Nos engagements

Nous ne versons pas de récompense financière, mais nous répondons et nous corrigeons.

• accusé de réception dans les 3 jours ouvrables;
• première évaluation et retour sur la recevabilité dans les 10 jours ouvrables;
• information sur la correction une fois celle-ci déployée;
• mention de votre nom dans nos remerciements si vous le souhaitez;
• aucune poursuite ni plainte de notre part contre un chercheur qui respecte les règles ci-dessous.

Règles à respecter

Ces règles délimitent le cadre dans lequel notre engagement de non-poursuite tient.

• s'en tenir à la preuve de concept minimale, sans aller au-delà de ce qui démontre la faille;
• ne pas accéder, modifier, extraire ni conserver de renseignements appartenant à un tiers, et interrompre le test dès qu'une telle donnée apparaît;
• aucun déni de service, aucun test de charge, aucun envoi massif par les formulaires;
• aucune ingénierie sociale ni hameçonnage visant nos employés, nos fournisseurs ou nos bureaux;
• ne pas divulguer la faille publiquement avant sa correction ou avant l'expiration d'un délai de 90 jours convenu ensemble.

Rapports que nous ne retenons pas

Les signalements suivants sont classés sans suite, faute de démonstration exploitable.

• les résultats bruts d'un outil de balayage, sans démonstration d'impact;
• l'absence d'un en-tête de sécurité ou d'un enregistrement DNS, sans exploitation associée;
• les faiblesses théoriques visant une suite de chiffrement encore largement acceptée;
• les scénarios qui exigent un accès physique à l'appareil de la victime ou un navigateur hors support;
• les rapports visant un service de tiers, à adresser directement à son éditeur.

Fichier security.txt

Un fichier conforme au RFC 9116 reprend ces coordonnées à la racine de nos domaines, pour les outils qui le recherchent automatiquement.