La sécurité des applications chez Scalingo #1 : Asgard

Chez Scalingo, la sécurité et la protection des données sont des enjeux majeurs. Notre démarche de mise en conformité ISO 27001 a rendu nécessaire la définition d’une stratégie pour référencer tous les actifs (matériels, logiciels, fournisseurs, etc.). Et bien qu’un document éditable soit suffisant pour les actifs statiques tels que le matériel et les fournisseurs, les actifs logiciels, eux, ne cessent d’évoluer. Avec plus de 350 dépôts de code, Scalingo ne peut se reposer sur un document texte pour tous les référencer et les maintenir à jour.

Dans cet article, vous découvrirez le projet développé au sein de l’équipe InfoSec (Information Security) pour répondre à ce besoin et l’impact qu’a cette solution sur la sécurité au sein de Scalingo.

Qu’est-ce qu’Asgard ?

Asgard, ça vous parle ? Les fans de mythologie nordique diront que c’est le domaine des dieux. Les fans de Marvel, eux, diront que c’est la demeure de Loki. Chez Scalingo, Asgard signifie autre chose. Curieux ? Asgard est le diminutif d’Application Security Guard.

Génial, mais qu’est-ce que c’est ? C’est un outil qui aide à maintenir la sécurité sur les actifs logiciels de Scalingo, notamment les référentiels de code source et les actifs binaires.

Pourquoi faut-il protéger les actifs ? Ils peuvent être exposés à des risques de nature malveillante ou accidentelle. Les risques sur ces actifs peuvent être un accès malveillant au code, une modification accidentelle de celui-ci ou encore une introduction de dysfonctionnements et de vulnérabilités dans le code. Ils se caractérisent par une introduction de code pouvant entraîner une fuite de données, un temps d’arrêt ou une altération de données.

Pourquoi Asgard ?

Auparavant, les actifs logiciels de Scalingo étaient référencés dans une base de données qui nécessitait l’intervention d’une personne pour mettre à jour son contenu. Cette opération devenait de plus en plus fastidieuse pour les développeurs de Scalingo avec la création de nouveaux dépôts de code. Honnêtement, personne n’a envie de faire ça. Et comme chez Scalingo, on avance à raison de 427 caractères à la minute, le document n’est pas à l’abri de l’erreur humaine.

Petit quiz : Avez-vous déjà passé 2h à écrire un script pour automatiser une action répétitive qui vous aurait pris autant de temps à le faire manuellement ? Êtes-vous toujours en train d’essayer d’optimiser la quantité d’effort que vous mettez dans votre travail ? Avez-vous déjà manifesté votre mécontentement face à une tâche que vous avez déjà faite à maintes reprises ?

Si vous avez répondu oui à toutes ces questions, félicitations, votre ADN est à 80% développeur et à 20% paresseux.

Bonne nouvelle… chez Scalingo, on l’est aussi. Là où les autres entreprises référencent leurs actifs sur des documents Excel, Scalingo, adepte de la culture Everything-as-code et de l’automatisation, décide d’adopter la Compliance-as-code en créant Asgard : un outil pour les développeurs de Scalingo qui référence les actifs logiciels, automatise l’évaluation des différents aspects de la sécurité, et uniformise les mesures de sécurité sur ces actifs.

Asgard, comment ça marche ?

Asgard se compose de deux parties, la partie serveur écrite en Ruby et la partie interface en ligne de commande (CLI) écrite en Go. Le serveur communique avec l'API GitHub qui, à partir des dépôts de code Git, fournit des métadonnées fondamentales pour l'évaluation de la sécurité. Les données reçues sont ensuite traitées et stockées dans une base de données pour être extraites si nécessaire.

Chaque dépôt de code est configuré à travers un fichier de métadonnées au format TOML. Les métadonnées représentent les attributs décrivant le dépôt de code. On y retrouve par exemple le propriétaire du dépôt, l’équipe qui en est responsable ou le langage utilisé.

Tout au long de leur journée de travail, mes talentueux et performants collègues sont amenés à pousser des changements dans le code source des différents dépôts GitHub (1). Tous les matins, Asgard procède à la synchronisation des métadonnées (2) en les récupérant depuis GitHub, notre outil de versioning de code source. S’en suit le traitement de ces métadonnées et l’évaluation de la sécurité de chaque dépôt de code (3). In fine, les utilisateurs peuvent à tout moment faire appel à Asgard pour obtenir des informations sur la sécurité ou sur les métadonnées des dépôts de code (4).

Les fonctionnalités

Dès le début, l’équipe InfoSec adopte la méthodologie Agile pour développer Asgard. Les récits utilisateurs découlent des besoins qu’ils ont exprimés, qu’ils soient de l’équipe InfoSec ou non. À plusieurs reprises, des sondages ont été réalisés auprès des futurs utilisateurs : les développeurs de Scalingo. Une approche centrée sur l’utilisateur final garantit que la fonctionnalité livrée répond aux attentes.

Asgard met à disposition plusieurs fonctionnalités pour faciliter la configuration de l’outil sur les dépôts de code, la récupération des informations et l’évaluation de la sécurité.

➜ ~ asgard

|~~~~/                                                |~~~~/
|    \                   ASGARD                       |    \
|~~~~~         Application Security Guard             |~~~~~
|_   _   _   _                           _   _   _   _|
| |_| |_| |_| |                         | |_| |_| |_| |
|__|__|__|__|_|                         |__|__|__|__|_|
|_|__/   \_|__|                         |_|__/   \_|__|
|__|_\___/__|_|  _   _   _   _   _   _  |__|_\___/__|_|
|_|__|__|__|__|_| |_| |_| |_| |_| |_| |_|_|__|__|__|__|
|__|__|__|__|_|__|__|__|__|__|__|__|__|_|__|__|__|__|_|
|_|__|__|__|__|_|__|__|_/+++++\___|__|__|_|__|__|__|__|
|__|__|__|__|_|__|__|__|+++++++||__|__|_|__|__|__|__|_|
|_|__|__|__|__|_|__|__||+++++++|__|__|__|_|__|__|__|__|
|__|__|__|__|__|_|__|__|+++++++||__|__|_||_|__|__|__|_|

NAME:
   ASGARD - Application Security Guard

USAGE:
   asgard command [command options] [arguments...]

AUTHOR:
   InfoSec Team <security@scalingo.com>

COMMANDS:
   help   Shows a list of commands or help for one command
   init   Initializes a metatdata file in your repository
   check  Checks the validity of the metatdata file in your repository
   get    Get a repository metadata
   list   Lists your organizations repositories
   audit  Audits your organizations repositories
   sync   Synchronize your repository in backend

Comment ajouter des métadonnées ?

Chaque équipe doit initialiser les métadonnées de ses dépôts de code Git. Rédiger un fichier de configuration pour chacun des 350 dépôts de code ? Non merci. Pas de panique, Asgard a ce qu’il vous faut. La commande init propose une interface en ligne de commande interactive sous forme de questionnaire à choix multiples. Pour chaque métadonnée, il sera affiché une liste de valeurs possibles. Ainsi, le développeur n’aura plus qu'à faire défiler les options et choisir celle qui correspond. La commande se charge ensuite de créer un fichier de configuration et d’y transcrire les options sélectionnées. Pas mal non ?

➜  ~ asgard init                        
? Who is the code owner ? siham@scalingo.com
? Who is the team responsible for this project ? InfoSec
? Describe your project in one sentence: 
? What kind of server is it deployed on ? (optional)  [Use arrows to move, space to select, <right> to all, <left> to none, type to filter]
  [ ]  app-hosting-node
  [x]  builder
  [ ]  database-hosting-node
> [x]  front
  [ ]  internal
  [ ]  scalingo-platform

Y-a-t-il moyen de vérifier la validité du fichier de métadonnées ?

Bien qu’il soit automatiquement généré avec la commande init, le fichier de configuration d’Asgard n’est pas à l’abri d’erreurs. Un développeur pourrait très bien y introduire une anomalie (ou s’amuser à tester les limites d’Asgard). Il a donc fallu créer une fonctionnalité qui vérifie que le fichier de configuration est correct. La commande check va parcourir le fichier de configuration présent en local sur votre machine et remonter les erreurs rencontrées. Plusieurs catégories d’erreurs peuvent être remontées :

• L’absence du fichier de configuration
• L’emplacement du fichier de configuration
• La taille du fichier de configuration
• L’absence des métadonnées obligatoires dans le fichier de configuration
• L’absence des métadonnées non obligatoires dans le fichier de configuration
• La validité de chaque métadonnée : type, taille, valeurs autorisées…

➜ example ~ asgard check               
[error] invalid field 'owner': value 'unknown@scalingo.com' is not valid
[error] empty field 'description'
[error] invalid field 'destination_server': field is not a list
[error] invalid field 'flags': value 'buildpak' is not valid

Est-il possible d’afficher une liste de dépôts de code ?

Asgard permet de visualiser la liste des dépôts de code. Cette liste reprend les métadonnées relatives à chaque dépôt de code et les affiche. On retrouve donc le propriétaire du dépôt de code, l’équipe qui en est responsable, le lien GitHub pour y accéder et s'il est déployé, le serveur de destination.

➜ ~ asgard list               
+-------------------+---------+---------+--------------------------------------+--------------------+
|       NAME        |  TEAM   |  OWNER  |              GITHUB URL              | DESTINATION SERVER |
+-------------------+---------+---------+--------------------------------------+--------------------+
| Scalingo/example1 | IST     | Leo     | https://github.com/Scalingo/example1 | internal           |
| Scalingo/example2 | UFS     | Kevin   | https://github.com/Scalingo/example2 | scalingo-platform  |
| Scalingo/example3 | InfoSec | Siham   | https://github.com/Scalingo/example3 | internal           |
| Scalingo/example4 | SRE     | John    | https://github.com/Scalingo/example4 | front              |
| Scalingo/example5 | InfoSec | Yannick | https://github.com/Scalingo/example5 | scalingo-platform  |
| Scalingo/example6 | IST     | Pierre  | https://github.com/Scalingo/example6 | builder            |
| Scalingo/example7 | IST     | Etienne | https://github.com/Scalingo/example7 | front internal     |
| Scalingo/example8 | UFS     | Jean    | https://github.com/Scalingo/example8 | scalingo-platform  |
| Scalingo/example9 | SRE     | Brandon | https://github.com/Scalingo/example9 | app-hosting-node   |
|         :         |    :    |    :    |                  :                   |          :         |
+-------------------+---------+---------+--------------------------------------+--------------------+

Et comme on est généreux dans l’équipe InfoSec, on a ajouté plein d’options pour filtrer la liste en fonction des métadonnées.

Qu’en est-il d’afficher les métadonnées d’un seul dépôt de code ?

Dans la commande list, on retrouve quelques-unes des métadonnées renseignées pour chaque dépôt de code. Pour retrouver l’ensemble des métadonnées d’un dépôt de code, la commande get est la solution.

➜ ~ asgard get example
+--------------------+-------------------------------------+
| NAME               | Scalingo/example                    |
| GITHUB URL         | https://github.com/Scalingo/example |
| OWNER              | Siham                               |
| TEAM               | InfoSec                             |
| DESCRIPTION        | I am an example repository.         |
| LANGUAGES          | ruby                                |
| FLAGS              | cli scalingo-app tools              |
| DESTINATION SERVER | internal                            |
| DEPENDENCIES       |                                     |
+--------------------+-------------------------------------+

Et si je veux voir mes changements instantanément ?

Les dépôts de code sont synchronisés sur Asgard tous les matins. Il arrive qu’un développeur (impatient) veuille visualiser les changements ou corrections qu’il a apportés aux dépôts de code sans attendre la prochaine synchronisation. La commande sync permet de récupérer instantanément depuis GitHub la dernière version d’un dépôt de code. Le développeur peut ensuite voir ses changements sur Asgard.

Et la sécurité dans tout ça ?

Une des fonctionnalités les plus cool d’Asgard est la commande audit. Asgard permet l’évaluation de la sécurité des actifs logiciels et se concentre sur 4 aspects :

• La vérification des métadonnées
• La vérification de la configuration Dependabot
• La vérification de la protection de branche
• La vérification de la divergence des branches

Vérification des métadonnées

La configuration des métadonnées étant nécessaire pour évaluer la sécurité des actifs, la première fonctionnalité implémentée dans l’audit a été l’évaluation de cette configuration qui permet de détecter les erreurs ou le manque de configuration sur les dépôts de code (un peu comme la commande check mais côté serveur).

➜  ~ asgard audit Scalingo/example               
+-------------------+--------------------------------------+
| NAME              | Scalingo/example                     |
+-------------------+--------------------------------------+
| ISSUES            |                                      |
| METADATA          | [e] missing metadata file            |
+-------------------+--------------------------------------+
| STATUS            | ERROR                                |
+-------------------+--------------------------------------+
TOTAL: 0 warning, 1 error

Vérification de la configuration Dependabot

Afin de garantir la fiabilité des dépendances, Dependabot doit être correctement configuré. Asgard vérifie que la configuration suit bien celle dont on a convenu en amont de l’implémentation de la fonctionnalité.

➜  ~ asgard audit Scalingo/example               
+-------------------+-----------------------------------------------------------------------+
| NAME              | Scalingo/example                                                      |
+-------------------+-----------------------------------------------------------------------+
| ISSUES            |                                                                       |
| DEPENDABOT        | [e] invalid field 'dependency-type' on 'ruby' configuration           |
+-------------------+-----------------------------------------------------------------------+
| STATUS            | ERROR                                                                 |
+-------------------+-----------------------------------------------------------------------+
TOTAL: 0 warning, 1 error

Vérification de la protection de branche

La protection de branche doit être configurée pour chaque dépôt de code. Tout comme Dependabot, Asgard vérifie que la configuration de la protection de branche suit bien celle dont on a convenu en amont de l’implémentation de la fonctionnalité.

➜  ~ asgard audit Scalingo/example               
+-------------------+--------------------------------------+
| NAME              | Scalingo/example                     |
+-------------------+--------------------------------------+
| ISSUES            |                                      |
| BRANCH PROTECTION | [e] branch 'master' is not protected |
+-------------------+--------------------------------------+
| STATUS            | ERROR                                |
+-------------------+--------------------------------------+
TOTAL: 0 warning, 1 error

Vérification de la divergence des branches

La branche principale, souvent appelée master ou main, est liée à l’environnement de pré-production de Scalingo. Cet environnement, aussi appelé staging, va permettre aux développeurs de tester de nouvelles fonctionnalités avant de les proposer aux utilisateurs. La branche liée à la production, qu’on appelle prod, va contenir le code déployé pour nos utilisateurs.

Scalingo suivant un processus de déploiement continu, les développeurs attendent parfois d’avoir plusieurs correctifs cumulés avant de les fusionner dans la branche “prod”. Mais si ce délai tarde trop, on a donc des correctifs, pouvant concerner la sécurité, qui “dorment” au lieu d’être déployés.

On appelle ceci une “divergence”. Rien à voir avec le film du même nom.

C’est ici qu’Asgard intervient en retournant le statut de la divergence des branches prod et master et les détails de cette divergence.

➜  ~ asgard audit Scalingo/example               
+-------------------+-------------------------------------------------------------------------------------------+
| NAME              | Scalingo/example                                                                          |
+-------------------+-------------------------------------------------------------------------------------------+
| ISSUES            |                                                                                           |
| DRIFT             | [w] master is 9 commits ahead of prod                                                     |
|                   | (showing 3 merge commits)                                                                 |
|                   | dev: Merge pull request #914 from Scalingo/feat/feat_description (3 weeks ago)            |
|                   | dev: Merge pull request #913 from Scalingo/feat/feat_description (1 month ago)            |
|                   | dev: Merge pull request #912 from Scalingo/fix/fix_description (2 months ago)             |
|                   | see https://github.com/Scalingo/example/compare/prod...master for more details            |
+-------------------+-------------------------------------------------------------------------------------------+
| STATUS            | OK                                                                                        |
+-------------------+-------------------------------------------------------------------------------------------+
TOTAL: 1 warning, 0 error

Les résultats

Asgard permet également de visualiser le résultat de l’audit de chaque dépôt de code dans une liste de problèmes. Ceci permet de détecter plus facilement les dépôts de code présentant des problèmes de sécurité.

➜ ~ asgard audit               
+-------------------+---------------------------------------------------------------------------+
|     REPOSITORY    |                                   PROBLEMS                                |
+-------------------+---------------------------------------------------------------------------+
| Scalingo/example1 | [error] invalid field 'dependency-type' on 'ruby' configuration (+1w +1e) |
| Scalingo/example2 | [error] missing metadata file (+2e)                                       |
| Scalingo/example3 |                                                                           |
| Scalingo/example4 | [warning] missing field 'destination_server' (+1e)                        |
| Scalingo/example5 | [error] invalid field 'dismiss_stale_review' (+1e)                        |
| Scalingo/example6 | [error] no 'javascript' configuration detected (+1e)                      |
| Scalingo/example7 |                                                                           |
| Scalingo/example8 | [error] branch 'master' is not protected                                  |
| Scalingo/example9 | [warning] master is 20 commits ahead of prod                              |
|         :         |                                      :                                    |
+-------------------+---------------------------------------------------------------------------+
TOTAL: 66 warnings, 827 errors

Comme on pouvait s’y attendre avec un si grand nombre de dépôts de code, Asgard a exposé un grand nombre d’incohérences entre nos dépôts de code et a certainement permis à nos équipes de prendre conscience de l’importance des processus de sécurité.

Futures fonctionnalités

Asgard a été publié en mars 2022 et ne cesse d’évoluer depuis ce jour, toujours pour automatiser et harmoniser la sécurité sur les actifs.

Comme tout bon produit qui a du succès, nous croulons maintenant sous les demandes et les idées, en voici un florilège :

• Notifications Slack
• Harmonisation des règles d’intégration continue
• Ajout du support Terraform et Bash
• Un leaderboard (=classement) par équipe (mais qui a demandé ça ?!)

Pour finir

La mission de l’équipe InfoSec est de déterminer les mesures de sécurité les plus efficaces pour Scalingo et de les mettre en œuvre. En adoptant une démarche de Compliance-As-Code, nous avons développé un outil aligné avec les valeurs de l’équipe et permettant d’harmoniser la sécurité du développement.

Avec cet article, j’avais envie de vous montrer la face cachée de Scalingo, révéler un peu les outils que nous mettons en place pour assurer le fonctionnement de la plateforme.

J’espère que vous avez apprécié !

Et si vous aussi vous aimez le cloud et la sécurité, rejoignez Scalingo ou envoyez nous une candidature spontanée !