L’approche shift left de Snyk pour le développement d’API

La plateforme de sécurité des développeurs de Snyk fournit aux développeurs et aux professionnels de la sécurité les outils nécessaires pour concevoir et exploiter des applications modernes en toute sécurité. Snyk permet aux utilisateurs d’intégrer la sécurité en amont et d’adopter un modèle DevSecOps. Les équipes modernes de développement d’applications savent que le shift left consiste à mettre les informations à la portée des développeurs le plus tôt possible dans le processus de développement, afin de créer des applications et des processus de développement efficaces et sécurisés.

Chez Snyk, nous adoptons ce même modèle shift left pour développer les API et les applications qui alimentent notre plateforme. Comme toute tâche spécialisée, le développement d’API nécessite des processus dédiés et des outils adaptés. En tant que plateforme API-first, il est essentiel d’obtenir des retours sur nos contrats d’API le plus tôt possible. Les API de Snyk donnent aux utilisateurs, au sein comme à l’extérieur de Snyk, accès à nos produits de sécurité de pointe. Les développeurs s’appuient sur Snyk et ses API pour alimenter leur cycle de développement logiciel (SDLC) et créer des applications sécurisées. Fournir des API de grande qualité est essentiel à la réussite de notre plateforme, et disposer d’un processus de développement d’API de grande qualité est indispensable pour les mettre à la disposition des utilisateurs.

Cet article présente quelques-uns des processus et outils que Snyk utilise pour créer sa plateforme API-first.

Pourquoi adopter le shift left ?

Depuis longtemps, les entreprises du secteur logiciel comprennent l’intérêt d’intégrer les tests, les opérations et la sécurité en amont. Au lieu d’attendre les revues ultérieures dans le SDLC, les développeurs peuvent obtenir rapidement des retours grâce à des méthodes comme l’intégration continue et à des outils tels que les plug-ins IDE de Snyk. Résultat : des livraisons plus rapides, une sécurité renforcée, des coûts réduits et un processus de mise en production des applications plus fiable dans son ensemble. La même approche shift left s’applique au développement d’API. Mieux vaut obtenir des retours tôt, idéalement à l’aide d’outils automatisés.

Guides de style et approche de Snyk

Le développement d’API RESTful est une forme particulière de développement d’applications qui nécessite les processus et les outils adaptés. Les API V3 de Snyk sont conçues pour offrir aux utilisateurs des moyens fiables, cohérents, faciles à comprendre et novateurs d’interagir avec la plateforme sous-jacente. Chez Snyk, nous définissons nos API avec OpenAPI (aussi appelé Swagger), la norme de facto pour définir les API RESTful. Toutefois, le simple fait de disposer d’une spécification d’API dans un format lisible par les machines et les humains ne garantit pas que les API répondront à nos objectifs en matière d’ergonomie. Les utilisateurs ont besoin d’API cohérentes sur l’ensemble de la plateforme afin d’interagir facilement avec ses différentes parties.

Pour assurer la cohérence de nos API, nous avons besoin de normes stylistiques. De nombreuses organisations utilisent un guide de style pour indiquer aux créateurs de contenu comment adopter un ton et un style cohérents. Snyk a élaboré son propre guide de style pour le développement d’API : l’API Stylebook, destiné aux équipes qui créent des API. À mesure que notre organisation se développe et que davantage de développeurs créent des API, notre guide nous aide à assurer leur cohérence et à offrir une expérience développeur uniforme. Mais disposer d’un guide de style ne suffit pas. Nous devons aussi fournir à nos développeurs des mécanismes pour vérifier qu’ils le respectent.

La revue manuelle est une façon de vérifier la conformité. Comme nos API sont spécifiées en OpenAPI et gérées dans un système de contrôle de versions, nous pouvons appliquer aux définitions d’API le même processus de revue qu’aux autres éléments de code. Les développeurs peuvent créer des demandes de fusion (PR) pour leurs modifications d’API et demander à un collègue de leur faire part de ses commentaires. Ce processus manuel peut être efficace pour garantir la conformité, mais, comme tout processus manuel, il est sujet aux erreurs humaines et ne se déroule pas toujours dans les délais. Snyk est une entreprise internationale qui privilégie le travail à distance. Attendre qu’un collègue examine votre PR d’API peut ralentir le processus et nuire à la productivité, surtout lorsque certaines étapes de la revue pourraient être automatisées. C’est là que notre approche de revue automatisée des API selon le principe du shift left prend tout son sens.

Les développeurs de Snyk qui créent des API disposent des trois éléments nécessaires pour effectuer une revue automatisée en local :

• La norme d’API de Snyk, exprimée sous forme d’un ensemble de règles

• L’API qu’ils ont décrite avec OpenAPI

• Des outils de linting capables de vérifier que la spécification OpenAPI rédigée par le développeur respecte les règles de la norme

Grâce aux outils de linting locaux pour leurs API, les développeurs obtiennent des retours en temps réel. Les développeurs de Snyk peuvent ainsi corriger les problèmes liés à leur API avant l’étape de revue manuelle. Le linter peut également être intégré à nos tâches CI pour vérifier la conformité. Comme toutes les équipes de développement utilisent les mêmes règles, la plateforme Snyk peut offrir une expérience API plus cohérente à ses utilisateurs.

Notre partenariat avec Optic

Après avoir décidé de représenter notre modèle de données avec REST, nous avons commencé à définir notre norme d’API avec JSON API. Une fois le projet de norme établi, nous avons voulu le rendre exécutable — une norme sous forme de code — afin d’éviter de bloquer les équipes de développement en attendant une « revue d’API par un expert ». Notre objectif était de fournir des retours rapides, conformément à notre philosophie shift left.

Les premiers outils que nous avons trouvés pour créer ces règles étaient très efficaces pour vérifier la syntaxe par correspondance de motifs, par exemple pour valider la conformité à OpenAPI 3. Mais nous avons rapidement constaté les limites de cette approche pour mettre en œuvre nos normes d’API. Ces règles sont fastidieuses à lire et à écrire (JSONPath et expressions régulières), et ne peuvent exprimer que des contraintes sur le contenu de la version actuelle de la spécification d’API évaluée. Nous avons décidé qu’il nous fallait une solution plus robuste et avons découvert qu’Optic était une excellente option.

Optic est un partenaire qui cherche à intégrer le shift left à ses produits de revue et de gouvernance des API, et qui prend en charge les flux de travail axés sur la conception d’API. Notre collaboration avec Optic dans ce domaine a abouti à Optic CI, un produit de linting d’API capable d’exprimer nos normes. Les règles d’Optic CI sont faciles à lire et à écrire grâce à un DSL de haut niveau en TypeScript. Surtout, Optic CI tient compte de la même réalité du développement d’API que Snyk : les API changent et évoluent sans cesse. Les règles s’appliquent aux changements apportés à une API, plutôt qu’à un instant donné. Elles sont ainsi suffisamment flexibles pour favoriser l’amélioration continue et l’évolution de nos API, et encadrer ces changements sans accumuler une montagne d’« exceptions de linting » à mesure que les normes évoluent.

La suite bientôt

Snyk s’engage à créer une plateforme axée sur les développeurs et les API. En appliquant le shift left à notre cycle de développement des API, nous apportons des retours à nos développeurs. Restez à l’écoute : dans notre prochain article sur le processus de développement des API chez Snyk, nous verrons comment nous utilisons des outils pour gérer les versions de nos API.

Envie de rejoindre l’équipe qui développe la plateforme Snyk ? Consultez nos postes ouverts en ingénierie et contribuez à notre mission de sécurisation du développement.