Sécurité et divulgation des vulnérabilités

Les bibliothèques de composants eSeGeCe sont intégrées dans des applications qui tournent en production, souvent exposées à internet. Nous prenons au sérieux les signalements de défauts de sécurité et nous préférons apprendre tôt l'existence d'un problème plutôt que d'en entendre parler plus tard ailleurs. Cette page décrit comment nous joindre, ce qui se passe après votre message et ce à quoi nous nous engageons en retour.

Signaler une vulnérabilité

Utilisez notre formulaire de contact en indiquant "sécurité" dans le sujet. Il atteint directement les développeurs, pas une file de tickets de premier niveau, et c'est notre point de contact unique pour les questions de sécurité. Vous n'avez besoin ni d'un contrat de support ni d'une licence valide pour signaler une vulnérabilité.

Merci d'inclure autant d'éléments que possible parmi les suivants :

• Produit, édition et version. Par exemple sgcWebSockets 2026.8.0 Enterprise, ou la révision exacte si vous compilez depuis les sources.
• Composant concerné. L'unité, la classe ou le protocole en cause, par exemple le serveur HTTP/2 ou le client MQTT.
• Environnement. Version de Delphi ou C++ Builder, plateforme cible et backend TLS utilisé si le problème concerne le transport.
• Reproduction. Un projet minimal, une capture réseau ou une suite d'étapes. Plus le cas est réduit, plus la correction est rapide.
• Impact. Ce qu'un attaquant obtient, et si une authentification ou une configuration particulière est nécessaire.

Si vous souhaitez chiffrer votre signalement, dites-le dans un premier message sans détail technique et nous conviendrons d'un canal avec vous.

Ce que nous faisons à la réception d'un signalement

• Accusé de réception sous 5 jours ouvrés. Vous recevez une réponse humaine confirmant la réception et indiquant qui s'en occupe.
• Évaluation sous 10 jours ouvrés. Nous confirmons ou écartons le constat, nous vous donnons notre appréciation de la gravité et un délai prévisionnel.
• Correction. Les défauts de gravité critique et élevée sont traités dans une version dédiée. Les constats de moindre gravité sont planifiés pour la version ordinaire suivante.
• Notification. La correction est décrite dans les notes de version livrées avec le produit et publiée dans le journal des modifications de ce site.
• Crédit. Nous citons l'auteur du signalement dans l'avis s'il souhaite être nommé, et nous gardons le silence sur son identité s'il le préfère.

Divulgation coordonnée

Nous vous demandons de nous laisser un délai raisonnable pour publier une correction avant toute publication de votre part, et le délai avec lequel nous travaillons est de 90 jours à compter de la date de votre signalement. Si un défaut fait l'objet d'une exploitation active, ou si une correction prend plus de temps que prévu, nous en discuterons avec vous plutôt que de laisser le compte à rebours s'écouler en silence. Nous n'engagerons aucune action en justice contre une personne qui signale une vulnérabilité de bonne foi et respecte cette politique.

Périmètre

Sont dans le périmètre les bibliothèques de composants eSeGeCe dans toutes leurs éditions prises en charge, dont sgcWebSockets, sgcSign, sgcOpenAPI, sgcIndy et sgcBiometrics, ainsi que le code d'exemple et les démos que nous distribuons, et ce site web.

Sont hors périmètre les constats qui ne concernent que des logiciels tiers que nous ne distribuons pas, les rapports produits par un scanner automatique sans impact démontré, et tout ce qui suppose d'attaquer notre infrastructure ou un autre client. Merci de ne pas mener de tests de déni de service, de ne pas attaquer nos serveurs par force brute et de ne pas accéder à des données qui ne sont pas les vôtres.

Signaler une vulnérabilité dans un composant que nous utilisons

Si votre constat porte sur un composant tiers sur lequel nous nous appuyons, comme Indy, zlib ou OpenSSL, signalez-le nous quand même. Nous transmettrons le signalement à ceux qui le maintiennent, comme l'article 13(6) du règlement européen sur la cyberrésilience nous l'impose, et nous suivrons la correction jusque dans nos propres versions.

Mises à jour de sécurité et période de support

Les corrections de sécurité sont livrées dans le cadre des versions normales du produit, publiées plusieurs fois par an avec le code source complet. Une licence inclut les mises à jour pendant sa période d'abonnement, et les corrections de sécurité d'une version majeure restent disponibles pendant au moins cinq ans à compter de sa publication. Comme chaque licence comprend le code source complet, vous ne dépendez jamais de nous pour inspecter, corriger ou recompiler le code que vous livrez.

Nomenclature logicielle (SBOM)

Nous tenons à jour, pour chaque version, un SBOM lisible par machine au format CycloneDX listant les composants de premier niveau à partir desquels nos produits sont construits ainsi que leurs licences. Le règlement sur la cyberrésilience impose aux fabricants de l'établir et de le conserver dans la documentation technique, il n'impose pas de le publier. Nous le fournissons donc sur demande plutôt que de le publier ici. Les licenciés et les autorités de surveillance du marché peuvent le demander via notre formulaire de contact, en précisant le produit, l'édition et la version concernés.

Contexte réglementaire

Si vous nous évaluez comme fournisseur au titre du règlement européen sur la cyberrésilience, règlement (UE) 2024/2847, notre déclaration sur ce que le CRA implique pour les produits construits avec les composants eSeGeCe figure sur une page distincte.

• Le règlement sur la cyberrésilience et les composants eSeGeCe

Contact

Tout ce qui figure sur cette page, y compris les signalements de vulnérabilités, nous parvient via notre formulaire de contact.