Comment Apivom aborde la sécurité du code source

La plupart des pages sécurité énumèrent des contrôles, puis s'arrêtent là. Cet article explique ce que nous faisons pour notre propre code source, ce que nous héritons des plateformes sur lesquelles nous nous appuyons, et ce que nous ne prétendons pas.

Trois pratiques sur deux plateformes

Le code d'Apivom est hébergé sur GitHub Enterprise Cloud, et la plateforme en production tourne sur Microsoft Azure. Nous imposons trois pratiques non négociables par-dessus :

• Une analyse automatisée des vulnérabilités des dépendances sur nos dépôts, avec GitHub Dependabot.
• L'authentification à deux facteurs, obligatoire pour tout ingénieur ayant accès au code source.
• Un pare-feu applicatif (WAF) et une protection DDoS devant la plateforme en production, avec Azure Front Door Premium.

Les sections suivantes détaillent chacune, puis tracent clairement la limite de ce que nous ne prétendons pas.

Analyse des dépendances : l'essentiel de votre code est celui des autres

Une application moderne est faite en grande partie de paquets écrits par d'autres. Chacun est du code que nous livrons : une vulnérabilité connue dans une dépendance est donc une vulnérabilité dans notre produit, même si nous n'en avons pas écrit une ligne.

Dependabot compare les dépendances de nos dépôts aux avis de sécurité publiés. Lorsqu'un paquet que nous utilisons présente une vulnérabilité connue, il émet une alerte et, si une version corrigée existe, ouvre une pull request de mise à jour. Cette pull request passe par la même revue et les mêmes contrôles qualité que n'importe quel autre changement.

L'analyse est automatique et toujours active : personne n'a à penser à la lancer. Le correctif est une pull request ordinaire, il ne demande donc aucun processus spécial.

Ses limites, sans détour : Dependabot détecte les vulnérabilités connues des dépendances. Il ne revoit pas le code que nous écrivons et ne peut pas repérer une faille que personne n'a encore signalée. Nous le traitons comme une couche de défense, pas comme une garantie.

L'authentification à deux facteurs pour toute personne qui touche au code

L'accès au code source fait partie des accès les plus sensibles d'une équipe d'ingénierie. Le mot de passe volé d'un compte capable de modifier le code est un chemin vers la production.

Nous imposons donc l'authentification à deux facteurs dans toute notre organisation GitHub, pour chaque ingénieur ayant accès au code source. C'est une obligation, pas une recommandation. Les réglages recommandés s'érodent avec le temps, alors qu'une obligation ne demande aucun suivi.

Nous avons décrit le même principe pour l'accès des partenaires dans Passkeys pour l'accès API des partenaires : lorsqu'un identifiant est lié à une personne, la piste d'audit prend tout son sens.

Ce que les certifications de GitHub signifient, et ce qu'elles ne signifient pas

Notre gestion du code source, nos revues de code et notre automatisation s'exécutent sur GitHub Enterprise Cloud. GitHub détient les rapports SOC 1 Type II, SOC 2 Type II et SOC 3, ainsi que les certifications ISO/IEC 27001:2022, ISO/IEC 42001:2023 et PCI DSS. GitHub fait aussi réaliser des tests d'intrusion par des tiers et gère un programme de bug bounty.

Ces certifications couvrent l'infrastructure et les opérations de GitHub. Elles ne certifient pas Apivom. Nous ne détenons pas, à ce jour, notre propre certification SOC 2 ou ISO/IEC 27001. Ce que nous affirmons sans détour : la plateforme qui héberge notre code est auditée de façon indépendante, et nos propres pratiques sont décrites ici dans leur intégralité — vous pouvez nous en demander des comptes.

La plateforme en production : Azure Front Door en frontal

L'infrastructure applicative d'Apivom s'exécute sur Microsoft Azure, en Europe de l'Ouest par défaut, ou dans votre propre tenant Azure lorsque vous voulez maîtriser entièrement l'emplacement des données. Le trafic public atteint la plateforme via Azure Front Door Premium, avec un WAF et une protection DDoS.

Un WAF filtre les requêtes avant même qu'elles n'atteignent l'application, réduisant l'exposition aux schémas d'attaque courants et aux abus automatisés. Il ne remplace pas un code sécurisé — c'est précisément pour cela que les pratiques décrites plus haut existent.

Ce que nous ne prétendons pas

• Nous ne détenons pas notre propre certification SOC 2 ou ISO/IEC 27001.
• Les certifications de GitHub appartiennent à GitHub, pas à Apivom.
• L'analyse des dépendances détecte les vulnérabilités connues, pas les inconnues.
• Rien de cela ne remplace votre propre diligence.

Quatre questions à poser à tout fournisseur

1. L'analyse des dépendances est-elle automatique, ou faut-il que quelqu'un y pense ?
2. L'authentification à deux facteurs est-elle imposée, ou seulement recommandée ?
3. À qui appartient la certification : au fournisseur, ou à sa plateforme d'hébergement ?
4. Où le trafic public entre-t-il, et qu'est-ce qui le filtre ?

Vous menez une revue de sécurité ? Posez-nous ces quatre mêmes questions — nous comptons bien y répondre. Notre politique de divulgation et notre contact sécurité se trouvent sur la page sécurité, et vous en saurez plus sur l'entreprise sur la page à propos.