Ingénieur DevSecOps

Comprendre la chaîne de livraison d'une application et ses points faibles : modéliser les menaces, identifier les actifs à protéger, poser un pipeline de base et définir ce que la sécurité doit y contrôler.

Un réseau de centres de santé implantés à Abidjan et à Marseille vient de lancer « Santé Proche », sa plateforme de prise de rendez-vous. Elle traite des données de santé, et la direction s'inquiète après une fuite chez un concurrent. Ce projet vous suivra jusqu'au sprint 7. Vous recevez le dépôt de l'application (API, interface web, base de données) et son pipeline minimal. Vous commencez par une modélisation des menaces : flux de données, frontières de confiance, actifs sensibles, scénarios d'attaque plausibles. Vous en tirez une liste de risques classés par probabilité et par impact. Vous proposez ensuite une feuille de route : quels contrôles ajouter au pipeline et à l'infrastructure, dans quel ordre, et à quel moment ils doivent bloquer une livraison. En soutenance, vous présentez cette analyse à la direction, jouée par le mentor, sans jargon inutile.

Repérer et corriger les failles du code avant la livraison : revue de code orientée sécurité, analyse statique automatisée dans le pipeline, scan des secrets dans l'historique Git et règles de blocage adaptées.

La feuille de route du sprint 1 fait de la sécurité du code la priorité. Le code de Santé Proche contient plusieurs failles du Top 10 de l'OWASP, et un ancien développeur a laissé des identifiants dans l'historique Git. Vous intégrez au pipeline un outil d'analyse statique et un détecteur de secrets, y compris sur l'historique complet du dépôt. Vous triez les résultats : vrais problèmes, faux positifs, points à surveiller. Pour chaque faille confirmée (injection, contrôle d'accès défaillant, exposition de données de patients…), vous écrivez une correction accompagnée d'un test qui prouve qu'elle n'est plus exploitable. Vous révoquez les identifiants exposés et nettoyez l'historique. Vous définissez enfin les règles de blocage du pipeline. Le mentor évaluera la pertinence de votre tri autant que vos corrections.

Sécuriser tout ce qui entre dans l'application et tout ce qui en sort : analyse des dépendances, inventaire des composants logiciels, politique de mise à jour, signature des artefacts et vérification de leur provenance.

Santé Proche embarque plusieurs centaines de bibliothèques open source, dont certaines n'ont pas été mises à jour depuis des années. Un hôpital partenaire exige désormais la liste précise des composants de tout logiciel qu'il utilise. Vous ajoutez au pipeline l'analyse des dépendances et vous traitez les vulnérabilités trouvées, en distinguant celles qui sont réellement atteignables. Vous générez à chaque construction un inventaire des composants logiciels dans un format standard, ainsi qu'une vérification des licences. Vous mettez en place des mises à jour automatisées des dépendances, encadrées par les tests. Vous signez enfin les artefacts produits par le pipeline et vous faites vérifier la signature et la provenance avant tout déploiement. En soutenance, le mentor tentera de déployer un artefact non signé : la chaîne doit le refuser.

Réduire la surface d'attaque des conteneurs : images minimales, exécution sans privilèges, scan des images dans le pipeline et dans le registre, durcissement de l'environnement d'exécution et isolation réseau.

Les images de Santé Proche pèsent plus d'un gigaoctet, tournent avec les droits d'administrateur et contiennent des outils inutiles qui faciliteraient la vie d'un attaquant. Vous reconstruisez les images à partir de bases minimales, en plusieurs étapes, pour n'y laisser que ce qui est nécessaire à l'exécution. Les conteneurs tournent sans privilèges, avec un système de fichiers en lecture seule quand c'est possible. Vous intégrez un scan des images dans le pipeline et dans le registre de votre fournisseur cloud, avec des seuils de blocage. Vous durcissez ensuite l'environnement d'exécution : capacités retirées, limites de ressources, règles réseau qui empêchent l'API de joindre autre chose que la base et les services autorisés. Votre rapport compare, pour chaque image, la taille, le nombre de vulnérabilités et les privilèges avant et après.

Gérer les identités et les secrets sur le cloud choisi : coffre de secrets, rotation automatique, identités de charge de travail sans clé statique, rôles au moindre privilège, accès humains limités et tracés.

Santé Proche utilise un seul compte de service cloud aux droits d'administrateur, dont la clé est copiée dans trois fichiers de configuration. Les mots de passe de la base n'ont jamais changé depuis le lancement. Vous déplacez tous les secrets dans le coffre de votre fournisseur cloud et vous mettez en place la rotation automatique du mot de passe de la base. L'application et le pipeline obtiennent leurs droits par des identités de charge de travail, sans aucune clé statique. Vous définissez un rôle par composant, limité aux seules actions nécessaires, et vous vérifiez ces droits avec les outils d'analyse du fournisseur. Les accès humains passent par une authentification forte, avec élévation temporaire pour les opérations sensibles, et toute action est journalisée. Vous livrez une matrice des identités et le résultat d'une tentative d'accès hors périmètre.

Empêcher les erreurs de configuration d'arriver en production : analyse de l'infrastructure as code, règles de conformité écrites en code, contrôle dans les pull requests et détection des dérives sur l'infrastructure déployée.

Lors d'un exercice, un stockage contenant des comptes rendus médicaux s'est retrouvé public après une modification de l'infrastructure. Personne ne l'a vu dans la relecture. Vous ajoutez au pipeline l'analyse du code d'infrastructure de Santé Proche et vous corrigez les mauvaises configurations trouvées. Vous écrivez ensuite vos propres règles de conformité en code, tirées des exigences du réseau de santé : aucun stockage public, chiffrement obligatoire au repos, journaux activés, régions d'hébergement autorisées, étiquettes de propriétaire sur chaque ressource. Ces règles s'appliquent dans chaque pull request, avec un message clair qui explique comment corriger. Vous mettez enfin en place la détection des dérives entre le code et l'infrastructure réellement déployée. En soutenance, le mentor proposera une modification non conforme : elle doit être bloquée avec une explication.

Tester l'application en fonctionnement, détecter les attaques en production et savoir réagir : analyse dynamique automatisée, journaux de sécurité centralisés, règles de détection, alertes et exercice de réponse à incident.

Santé Proche va passer en production dans les deux villes. Le réseau veut savoir si l'application résiste à des attaques réelles et, surtout, s'il saura les voir. Vous intégrez au pipeline une analyse dynamique qui attaque l'application déployée en recette, et vous traitez les résultats. Vous centralisez ensuite les journaux de sécurité : application, pare-feu applicatif, accès au cloud, identités. Vous écrivez des règles de détection pour des scénarios précis, comme un grand nombre d'échecs de connexion, la consultation massive de dossiers de patients ou l'usage d'une identité depuis une région inhabituelle. Chaque alerte renvoie vers une procédure de réponse. En soutenance, le mentor rejoue une attaque sur la recette : vous la détectez, la contenez et rédigez le compte rendu d'incident.

Auditer puis sécuriser la chaîne de livraison complète d'un projet réel issu d'une mission Formuloo, en s'appuyant sur les règles de sécurité de nos équipes, puis défendre son travail devant un jury.

Ce dernier sprint vous confie la chaîne de livraison d'un projet réel issu d'une mission Formuloo, par exemple une plateforme de paiement, un service de mobilité ou une application de commerce en ligne. Vous recevez l'accès au dépôt, au pipeline et à un environnement de recette, ainsi que le référentiel de règles de sécurité appliqué par les équipes de Formuloo : chiffrement des échanges entre services, droits cloisonnés par service, rotation des jetons, journal d'audit, double validation des opérations sensibles. Vous commencez par un audit de l'écart entre ce référentiel et l'existant. Vous priorisez avec le client, joué par un membre de l'équipe Formuloo, puis vous mettez en place les contrôles manquants dans le pipeline et l'infrastructure, sans dégrader la vitesse de livraison. La soutenance finale, devant un jury, porte sur cette mission et sur votre portfolio des huit sprints.