Associez facilement les vulnérabilités Snyk aux services Cortex

Snyk est une plateforme de sécurité cloud native conçue pour les développeurs. Elle détecte les vulnérabilités dans le code, les dépendances, les conteneurs et l’infrastructure as code. Snyk repère efficacement les vulnérabilités dans votre base de code, mais il peut être difficile de relier ces problèmes aux services concernés et à leurs propriétaires. Heureusement, l’API robuste de Snyk permet de configurer la plateforme pour l’intégrer à des solutions conçues pour aider les équipes d’ingénierie à comprendre et à améliorer leur architecture orientée services.

Cortex est l’un de ces outils. Il répertorie automatiquement les services internes et leurs dépendances, et s’intègre à des outils tiers (comme Snyk) pour offrir une vue centralisée de votre architecture. En utilisant Cortex avec Snyk, les entreprises peuvent non seulement obtenir une vue complète de leur architecture de microservices, mais aussi connaître les vulnérabilités qui s’y trouvent.

Cortex enrichit la plateforme Snyk en permettant de :

1. Associer automatiquement les vulnérabilités aux microservices existants

2. Regrouper les vulnérabilités Snyk dans la chronologie du service afin de les consulter dans le contexte d’autres indicateurs importants, comme les incidents ayant nécessité une intervention d’astreinte

3. Mesurer et améliorer la qualité des services à partir des données de Snyk et d’autres intégrations, grâce aux Scorecards

Associer les vulnérabilités à un service

Comment cela fonctionne-t-il ?

Après avoir configuré Snyk dans Cortex, nous interrogeons l’API de reporting de Snyk pour récupérer les problèmes les plus récents concernant le service. Nous les affichons ensuite dans l’onglet Snyk du service, où vous pouvez également consulter d’autres informations à son sujet. Vous pouvez appliquer des filtres supplémentaires pour trouver rapidement ce que vous cherchez.

Pourquoi est-ce important ?

Les ingénieurs peuvent consulter rapidement les problèmes Snyk associés à un service et donner la priorité à la résolution des plus critiques.

Snyk dans la chronologie du service

En plus de consulter les problèmes Snyk de chaque service, vous pouvez les voir à côté d’autres événements liés au service, comme les changements Kubernetes, les commits Git, les déploiements et les incidents ayant nécessité une intervention d’astreinte, le tout dans une seule chronologie. Cette fonctionnalité est particulièrement utile lors d’un incident, lorsque vous devez rapidement en trouver la cause première.

Intégration aux Scorecards

Maintenant que vous disposez des données Snyk pour chaque service, vous pouvez créer des Scorecards. Elles vous permettent de définir des bonnes pratiques pour un ensemble de services et d’évaluer leur respect de ces règles. Grâce à l’intégration Snyk, vous pouvez vérifier :

1. Si un service est associé à des projets Snyk (la détection automatique tentera de les identifier à partir du nom du dépôt)

2. Le nombre total de problèmes (non ignorés et non corrigés)

3. Le nombre total de problèmes, avec la possibilité de filtrer par gravité et selon qu’ils peuvent être corrigés ou non

Vous pouvez combiner ces règles à d’autres pour mesurer le niveau de préparation opérationnelle d’un service. Une Scorecard configurée de cette manière vous aide à déterminer quand un service est prêt à être déployé en production. Vous pouvez vérifier la présence de runbooks, de tableaux de bord, de journaux, de politiques d’escalade d’astreinte et de responsables clairement identifiés, ainsi que l’absence de vulnérabilités :

• owners.count > 2 - Des responsables sont définis pour le service. En cas d’incident, l’équipe chargée d’intervenir est donc clairement identifiée.

• oncall escalations count > 1 - La politique d’escalade comporte au moins deux niveaux. Ainsi, si la première personne d’astreinte ne confirme pas la prise en charge, une autre personne peut intervenir.

• runbooks count >= 1 - Des runbooks sont disponibles pour le service, ce qui favorise une culture de la préparation.

• number of links (type = logs) > 1 - En cas d’incident, les personnes chargées d’intervenir peuvent facilement trouver les bons journaux (généralement ceux de l’équilibreur de charge et de l’application).

• dashboards count >= 1 - Un tableau de bord Grafana standard est défini pour le service.

• Compare custom data to boolean: "pre-prod-enabled" = true - Utilisez un processus asynchrone pour vérifier si le service dispose d’un environnement de préproduction actif, puis envoyez une valeur booléenne (true/false) à Cortex via l’API de métadonnées personnalisées.

• Snyk issues with HIGH severity = 0 – Veillez à ce qu’aucun service de production ne soit déployé avec des vulnérabilités.

Une fois cette Scorecard configurée, vous verrez une liste des services classés selon leur évaluation au regard de ces règles.

Commencer

La mise en route est simple : il vous suffit d’ajouter l’identifiant de votre organisation et votre clé API dans votre page des paramètres. Nous associerons alors les services au projet Snyk lié au dépôt, directement dans le catalogue des services.

Vous pouvez ensuite accéder à vos Scorecards et ajouter quelques-unes des règles ci-dessus. Vous pourrez alors évaluer la qualité de vos services à partir des vulnérabilités détectées dans votre base de code ! Si vous avez des questions ou besoin d’aide pour configurer cette intégration, écrivez à team@getcortexapp.com.

Cristina Buenahora Bustamante est ingénieure fondatrice chez Cortex