Skip to main content

Comment Axel Springer National Media and Tech a instauré une sécurité continue avec Snyk

Écrit par
feature customer axel springer

3 septembre 2024

0 minutes de lecture
How Axel Springer NMT Automated Dev-First Security in the SDLC

Lors du AWS Summit de Berlin cette année, l’équipe Snyk a eu l’occasion d’échanger avec Michael Steiner, client de Snyk et RSSI d’Axel Springer National Media and Tech. Ils ont parlé de notre partenariat avec son équipe, notamment de sa décision d’utiliser Snyk après Log4Shell, de l’intégration de Snyk Code et Snyk Open Source aux processus de développement existants et des résultats précis que l’équipe mesure aujourd’hui. Poursuivez votre lecture pour en savoir plus sur le parcours d’Axel Springer vers une sécurité intégrée en amont du cycle de développement.

Présentation d’Axel Springer National Media and Tech

Axel Springer est un éditeur numérique de premier plan en Europe. Sa division National Media and Tech propose des services technologiques et des produits numériques pour les journaux et d’autres marques de médias. Plus de 600 marques utilisent les solutions de journalisme numérique d’Axel Springer, et plus de 3 millions d’utilisateurs uniques se servent de ses produits et applications numériques.

L’équipe d’Axel Springer a adopté une structure organisationnelle horizontale, dans laquelle les équipes de développement partagent la responsabilité de l’assurance qualité, de l’informatique et de la sécurité. Elle estime que les développeurs, étant au plus près de leurs produits, sont les mieux placés pour intégrer ces étapes de manière transparente. Dans le cadre de ce modèle horizontal, les développeurs d’Axel Springer exécutent principalement leur propre infrastructure as code (IaC) sur AWS.

« Nous n’avons pas une grande équipe de sécurité ni de SOC, explique Steiner. Nous pensons que les développeurs peuvent s’en charger. L’idée est de mettre en place des outils qui les aident à corriger les vulnérabilités le plus tôt et le plus efficacement possible, tout en prenant en charge les processus automatisés. »

Le défi de processus et d’outils de sécurité incohérents

Avant de mettre en place Snyk, Axel Springer ne disposait pas d’un processus cohérent à l’échelle de l’entreprise pour détecter et corriger les vulnérabilités du code. L’équipe utilisait certains outils AppSec open source, comme SonarCloud, mais ne les avait pas déployés dans toute l’entreprise. De plus, cette approche ne fournissait qu’une analyse statique du code à certaines équipes et ne couvrait pas d’autres aspects importants de la structure de développement des applications de l’organisation, comme l’IaC, l’open source et les conteneurs.

Par ailleurs, l’équipe d’Axel Springer ne disposait d’aucune visibilité de bout en bout sur ses applications, ce qui compliquait l’identification des vulnérabilités présentes dans les dépôts. Les équipes de développement géraient aussi manuellement tous les processus de sécurité, ce qui demandait beaucoup de temps et d’efforts. Par exemple, en réponse à Log4Shell, elles ont compilé manuellement dans un tableur les données d’utilisation à l’échelle de l’entreprise, puis pris des mesures correctives en fonction de leurs conclusions.

« Nous n’avions pas de véritable processus, du moins pas à l’échelle de toute l’entreprise… Nous n’avions pas non plus de visibilité sur les vulnérabilités. Même les équipes elles-mêmes ne savaient pas combien de vulnérabilités se trouvaient dans leurs dépôts. »

- Michael Steiner, RSSI, responsable du centre de compétences Qualité et Sécurité informatique, Axel Springer

Intégrer la sécurité en amont avec Snyk Code et Snyk Open Source

Alors que la plupart des équipes d’Axel Springer National Media and Tech utilisaient des processus manuels pour repérer les occurrences de la vulnérabilité Log4Shell, une équipe menait une preuve de concept (POC) avec Snyk. Elle a pu voir Snyk à l’œuvre : l’outil a rapidement repéré les utilisations de Log4Shell dans ses dépôts, et l’équipe a pu agir en une fraction du temps nécessaire jusque-là.

Selon Steiner : « Avec la [POC] Snyk, il était très facile de découvrir dans quelle mesure cette équipe était touchée par la vulnérabilité. C’est ce cas d’usage que nous avons présenté à la direction pour lui dire : “Nous avons besoin de ce type d’outils pour bénéficier d’une telle transparence, surtout lorsqu’une vulnérabilité est découverte.” »

Après cet incident, l’équipe d’Axel Springer a mis en place Snyk Code et Snyk Open Source, afin de permettre aux développeurs de détecter et de corriger les vulnérabilités dès les premières étapes du pipeline.

« Nous utilisons actuellement Snyk Code et Snyk Open Source sur plus de 700 dépôts, et 300 développeurs se servent de ces outils… Nous les avons intégrés aux IDE et aux pipelines, connectés à Jira, et avons automatisé de nombreux processus, tout cela grâce à Snyk. »

- Michael Steiner, RSSI, responsable du centre de compétences Qualité et Sécurité informatique, Axel Springer

L’équipe Snyk s’est intégrée à l’ensemble du cycle de développement logiciel d’Axel Springer selon les étapes suivantes :

  • Analyse depuis l’environnement de développement intégré (IDE) et proposition de correctifs lors des demandes de tirage

  • Analyse dans le pipeline CI/CD à l’aide d’un scanner en ligne de commande (CLI)

  • Synchronisation de tous les dépôts existants avec Snyk afin de détecter les vulnérabilités plus tard dans le pipeline et d’en avertir les équipes responsables

  • Détection des vulnérabilités en production (par exemple, vulnérabilités zero-day et nouvelles menaces)

Une visibilité complète sur la sécurité chez Axel Springer

Aujourd’hui, l’équipe d’Axel Springer National Media and Tech analyse plus de 90 % de ses dépôts pertinents. Grâce à cette couverture élevée, elle bénéficie d’une visibilité complète sur les vulnérabilités du code existant et des dépendances open source, et peut corriger en continu les nouvelles vulnérabilités tout au long du cycle de vie du développement logiciel (SDLC).

Steiner explique : « Nous bénéficions désormais de cette transparence et pouvons encourager les équipes à mettre en place des processus pour corriger les vulnérabilités en continu. C’est important, car vérifier les vulnérabilités de temps à autre ne suffit pas. Cette transparence nous aide aussi à aborder ces sujets avec la direction. Je pense que cette visibilité est la valeur la plus importante que nous en tirons, et Snyk nous l’apporte. »

À l’avenir, l’équipe espère utiliser plus souvent les fonctionnalités de conformité des licences de Snyk Open Source. Elles l’aideront à décider quels produits ou dépôts vendre à d’autres entreprises en fonction des exigences de licence de ces clients potentiels.

L’équipe évoluera également vers une approche davantage fondée sur les risques. Elle prévoit de commencer à étiqueter les projets selon leur criticité métier et de hiérarchiser les vulnérabilités en fonction d’un score de risque qui évalue avec précision leur impact potentiel sur l’organisation. Elle pourra ainsi donner la priorité aux corrections les plus importantes, en fonction de l’emplacement exact de chaque vulnérabilité. Elle prévoit d’adopter Snyk AppRisk pour soutenir ces initiatives.

Lire la suite

Blog

Les modèles de pointe ont trouvé les vulnérabilités. Seul l’attaquant a trouvé les chaînes d’exploitation.

L’analyse statique a détecté les failles, mais seuls des tests d’attaque en conditions réelles ont prouvé comment elles pouvaient être enchaînées pour provoquer des compromissions. Comparaison d’Evo COS, de Claude Security et de Claude Code Security.

feature insights context
Blog

Les attaques autonomes sont déjà là. La défense doit suivre leur rythme.

Les attaquants autonomes réduisent la fenêtre de défense. Découvrez comment la découverte, la correction, la validation et la prévention continues peuvent aider les équipes de sécurité à suivre le rythme.

Blog

Pourquoi les agents de codage IA créent-ils sans cesse des failles de contrôle d’accès ?

Les agents de codage IA peuvent générer une logique d’autorisation qui compile et passe la revue, tout en exposant les données d’un tenant à un autre. Découvrez pourquoi les failles de contrôle d’accès sont difficiles à détecter et comment les prévenir.