La sécurité chez SecureCodingHub

Toutes les données au repos sont chiffrées avec un chiffrement AES-256. Les volumes de bases de données, les sauvegardes et le stockage de fichiers sont tous chiffrés avec des clés gérées via un service dédié de gestion des clés.

Toutes les communications entre les clients et nos serveurs utilisent TLS 1.3. Nous imposons HTTPS sur tous les endpoints, avec des en-têtes HSTS et une supervision de la transparence des certificats.

Les données clients sont logiquement isolées au niveau applicatif. Les données de chaque organisation sont cloisonnées par des contrôles d'accès stricts, garantissant l'absence de fuite de données entre tenants.

Les clients entreprise peuvent intégrer leur fournisseur d'identité via l'authentification unique SAML 2.0. Nous prenons en charge tous les principaux IdP, notamment Azure AD, Okta et OneLogin.

La prise en charge MFA ajoute une couche de sécurité supplémentaire aux comptes utilisateurs. Nous prenons en charge les applications d'authentification TOTP pour la vérification du second facteur.

Les sessions sont sécurisées par cryptographie avec des jetons à durée de vie courte, une expiration automatique et des capacités de révocation. Les sessions inactives sont terminées après une période d'expiration configurable.

Nous réalisons régulièrement des tests d'intrusion tiers sur notre infrastructure et notre application. Les constats sont triés, priorisés et corrigés en fonction de leur sévérité.

Notre pipeline CI/CD inclut une analyse automatisée des dépendances et une analyse de composition logicielle. Les vulnérabilités connues des bibliothèques tierces sont signalées et traitées rapidement.

Nous maintenons un programme de divulgation responsable destiné aux chercheurs en sécurité. Si vous découvrez une vulnérabilité, signalez-la-nous et nous travaillerons avec vous pour la résoudre.

Nous ne collectons que les données nécessaires à la fourniture de nos services. Nous ne collectons pas d'informations personnelles inutiles et nous ne revendons pas les données utilisateurs à des tiers.

Les données ne sont conservées que le temps nécessaire à la réalisation des finalités pour lesquelles elles ont été collectées. Lorsque les données ne sont plus requises, elles sont supprimées de manière sécurisée ou anonymisées.

Les utilisateurs peuvent demander à tout moment la suppression de leur compte et des données associées. Nous traitons les demandes de suppression rapidement et confirmons leur achèvement sous 30 jours.

Toute modification déployée en production passe par une revue de pull request impliquant au moins un ingénieur extérieur au binôme de travail immédiat de l'auteur. La CI exécute les contrôles unitaires, d'intégration et de sécurité à chaque push. Les déploiements en production passent par une étape d'approbation distincte. Les modifications d'urgence suivent une procédure « bris de glace » documentée, avec revue rétrospective la même semaine. Les modifications d'infrastructure sont gérées comme du code et examinées via le même workflow que le code applicatif.

L'analyse de composition logicielle s'exécute à chaque pull request, puis chaque nuit sur la branche principale. Les avis de sévérité critique et élevée déclenchent une alerte vers l'ingénieur d'astreinte avec une fenêtre de correction cible mesurée en jours, pas en semaines. Les avis moyens et faibles sont regroupés pour une revue hebdomadaire. Les images de base des conteneurs sont reconstruites à une fréquence fixe, afin que les correctifs transitifs du système d'exploitation atteignent la production sans nécessiter de modifications applicatives.

Le plan de réponse aux incidents définit quatre niveaux de sévérité, des chemins d'escalade et un point unique de responsabilité par incident. Le premier intervenant prend en charge le confinement et la communication client tandis qu'un enquêteur dédié suit la piste technique. Les revues post-incident sont sans recherche de fautif et produisent un compte rendu écrit avec des actions suivies jusqu'à clôture. Le plan est répété au moins deux fois par an sur des scénarios scriptés, afin que la mémoire des gestes existe avant un incident réel.

Si votre équipe sécurité découvre quelque chose lors d'un test d'intrusion contractuel, d'une revue interne ou d'un usage courant du produit, signalez-le directement à notre équipe sécurité plutôt que d'en discuter publiquement en premier. Nous accuserons réception sous deux jours ouvrés, partagerons un identifiant de suivi et fournirons des mises à jour de statut jusqu'à la clôture du problème. Nous considérons la divulgation coordonnée comme un partenariat.

Les administrateurs clients contrôlent l'attribution des rôles au sein de leur tenant. Le principe que nous recommandons est le même que celui que nous appliquons en interne : attribuer le rôle le plus restrictif qui permet à un utilisateur de faire son travail, et réviser les attributions à un rythme régulier. L'accès administratif en particulier doit être limité à un petit groupe nommément désigné, et ce groupe doit être audité au fur et à mesure des changements de rôle au sein de votre organisation.

Lorsqu'une personne quitte votre organisation, sa désactivation dans votre fournisseur d'identité doit se propager via SCIM pour supprimer son accès à la plateforme. Nous recommandons vivement le provisionnement SCIM plutôt que la gestion manuelle des utilisateurs pour toute organisation de plus de trente sièges. Si vous ne pouvez pas adopter SCIM aujourd'hui, une checklist d'off-boarding au niveau du compte avec un propriétaire désigné constitue le meilleur contrôle de remplacement.

Une page d'état couvrant la disponibilité de la plateforme et les incidents de dégradation de service. Une liste des sous-traitants. L'avenant actuel de traitement des données. Cette page de sécurité elle-même. Une fois la certification SOC 2 Type II obtenue, le rapport sera disponible sous NDA sur demande via votre contact de compte. Les mises à jour matérielles de politique qui concernent les clients sont annoncées via votre contact de compte plutôt qu'enfouies dans un changelog.

Les schémas d'architecture réseau interne, les flux d'authentification détaillés, l'outillage spécifique utilisé par notre équipe sécurité, les calendriers de rotation des clés au niveau individuel, ainsi que les noms et fonctions des membres de l'équipe sécurité. L'un de ces éléments peut être examiné sous NDA si la conversation le justifie — par exemple lors d'une revue de sécurité menée par les achats — mais ils n'ont pas leur place sur une page publique. Les publier abaisserait le coût d'une attaque ciblée sans apporter de réel bénéfice à un quelconque client.