Une revue de code par un autre développeur est obligatoire avant de pouvoir intégrer et à fortiori déployer le code.
A chaque commit validé par la code-review, plusieurs milliers de tests unitaires, d'integration, d’API, et fonctionnels sont exécutés.
Tout code, correctif, évolution applicative ou d’infrastructure est testé sur un environnement de staging avant d’être promu en production.
Avant chaque release, plusieurs centaines de tests bout-en-bout sont exécutés sur les principaux flow applicatifs, en plus d’une validation manuelle des différents changements apportés.
L’accès à l’application peut être occasionnellement suspendu en raison d'interventions de maintenance nécessaires au bon fonctionnement et à l’amélioration continue du service, et notamment de manière programmée. Dans ces cas, nous nous engageons à prévenir par email au minimum deux jours avant les opérations de maintenance.
Nous utilisons un certain nombre d'outils qui nous évitent d’introduire des erreurs. Ceux-ci sont au coeur de nos développement.
Parmi ceux-ci, nos frameworks comme Ruby on Rails et ReactJS, qui permettent d’en éviter un certain nombre sans faire d'effort explicite (XSS, SQL injection, Timing Attacks etc.). Nous effectuons une maintenance proactive de ces dépendances en évaluant la pertinence et la maturité de leurs évolutions pour notre codebase.
Nous utilisons également Datadog ASM sur notre environnement de staging qui permet de faire tourner l’application avant sa promotion en production et d’être alertés, ainsi que Snyk pour nous alerter notamment des CVE dès qu’elles sont publiées (les CVEs sont souvent reprises par l’ANSSI, par exemple dans un document comme celui-ci : https://www.cert.ssi.gouv.fr/avis/CERTFR-2019-AVI-111/).
Nous utilisons RuboCop, un outil d'analyse statique pour vérifier l'ensemble du backend. RuboCop possède un volet sécurité qui permet d’identifier les patterns à risque, c.f. https://rubocop.readthedocs.io/en/latest/cops_security/. Nous sommes également en train de mettre en place https://brakemanscanner.org/ pour prévenir des patterns dangereux plus avancés. Côté frontend, nous avons l’équivalent eslint.
Enfin, nous utilisons Brakeman pour l’analyse statique plus poussée de la sécurité de notre backend.
En outre, toute nouvelle fonctionnalité doit faire l’objet d’une Design Review avec une revue des impacts sécurité obligatoire et revue par le leadership technique.
Nous sommes prévenus dès la sortie d’une CVE impactant l’une de nos librairies ou dépendances. Il nous prévient également en cas de régression d’un fix sur une CVE connue. Par ailleurs Scaleway, DigitalOcean, Salesforce et nos autres partenaires fixent proactivement les CVE sur l’infrastructure et les OSes déployés.
Nous utilisons JIRA pour la gestion des tickets de sécurité, et leur donnons une priorité cohérente avec leur potentiel d’impact.