Déplacer la sécurité vers la gauche de façon responsable grâce au contrôle renforcé de Snyk sur les pull requests

Nous sommes ravis d’annoncer le renforcement des tests de sécurité et de licences de Snyk pour les pull requests, afin de mieux soutenir l’approche shift left en matière de sécurité et les workflows de développement sécurisé !

Les pull requests, piliers des workflows de développement basés sur GitHub, facilitent la collaboration sur les projets. Les contributeurs peuvent partager les modifications apportées à une branche d’un dépôt, en discuter avec d’autres collaborateurs, puis les valider et les fusionner dans la branche principale.

Conçu pour permettre aux développeurs et aux équipes de sécurité d’intégrer les tests de sécurité à ces workflows, et ce, le plus tôt possible dans le cycle de développement logiciel (SDLC), Snyk teste automatiquement les modifications incluses dans les pull requests afin de détecter les vulnérabilités et les problèmes de licences. Lorsqu’un problème est détecté, le test Snyk échoue et le développeur en est informé par un contrôle d’état correspondant. Pour éviter que les tests de sécurité de Snyk sur les pull requests ne perturbent les pipelines de développement, les utilisateurs peuvent choisir précisément dans quels cas les contrôles d’état échouent, par exemple uniquement en présence de problèmes critiques ou lorsqu’un correctif est disponible.

Les dernières améliorations apportées aux tests de sécurité de Snyk pour les pull requests vont encore plus loin. Pour éviter davantage les interruptions inutiles des pipelines de développement et donner aux développeurs une visibilité complète sur les résultats des tests de sécurité Snyk, ceux-ci peuvent désormais voir en détail pourquoi leur pull request a échoué, puis demander à l’administrateur d’ignorer le test et de forcer la validation de la pull request.

Voyons comment cela fonctionne à l’aide de quelques exemples simples.

Contrôles d’état Snyk pour les pull requests

Une fois que GitHub a vérifié l’absence de conflits et exécuté les contrôles sur les fichiers manifestes du projet (par exemple, package.json / package.lock, requirements.txt ou Gemfile.lock / Gemfile), Snyk effectue les tests de sécurité. Si les modifications n’introduisent aucune vulnérabilité, le test réussit haut la main :

En revanche, si les modifications introduisent des vulnérabilités, les contrôles d’état de Snyk font échouer la pull request. Dans l’exemple ci-dessous, l’ajout d’une dépendance a entraîné l’échec des tests de sécurité Snyk :

Quel que soit le nombre de projets (et de fichiers manifestes associés) dans un dépôt, seuls deux contrôles d’état Snyk s’affichent : l’un pour les tests de sécurité et l’autre pour les contrôles de licences. C’est particulièrement utile pour les mono-dépôts, car cela réduit le nombre de contrôles d’état Snyk affichés pour les projets intégrés.

Les administrateurs peuvent configurer les tests de sécurité Snyk pour les pull requests de façon à les rendre plus stricts ou plus souples. Par exemple, ils peuvent faire échouer les tests si le dépôt contient des vulnérabilités préexistantes ou uniquement si des vulnérabilités critiques sont introduites.

Ignorer les tests de sécurité échoués

Voir des contrôles d’état échouer sur des pull requests peut être frustrant pour les développeurs, surtout lorsqu’aucune information contextuelle n’explique la cause de l’échec. Snyk offre à la fois une visibilité sur les vulnérabilités et les problèmes de licences détectés pendant le test, et la possibilité de contourner le test échoué et de le valider de force.

Si une pull request échoue aux tests Snyk, les utilisateurs de Snyk peuvent en connaître les raisons en cliquant sur le lien Détails affiché à côté de l’état du contrôle ayant échoué. Ils accèdent alors à l’application Snyk, où toutes les informations expliquant l’échec des tests figurent sur la page État combiné :

Tous les contrôles pertinents effectués pour le projet s’affichent avec les résultats et leur état : « Erreur » pour les tests qui n’ont pas pu être terminés, « Échec » pour ceux qui ont échoué en raison de problèmes détectés, « En cours » pour ceux qui sont toujours en cours et « Réussi » pour ceux qui ont passé les tests.

Les utilisateurs désignés comme collaborateurs peuvent demander à un administrateur Snyk de forcer la validation d’un ou de plusieurs tests affichés sur cette page.

Les administrateurs peuvent cliquer sur le bouton Marquer comme réussi dans SCM pour répondre à la demande. L’état est automatiquement mis à jour dans GitHub.

Chaque action d’ignorance effectuée pour forcer la validation d’un test de sécurité échoué est consignée à des fins de référence ultérieure. Le journal indique qui a effectué l’action et à quel moment, et comprend un lien vers la page État combiné.

Une approche shift left sous supervision

Déplacer la sécurité vers la gauche est essentiel à la mise en œuvre réussie d’une stratégie DevSecOps, mais cette démarche doit être menée de façon responsable. Pour cela, il faut donner aux développeurs les moyens d’intégrer la sécurité à leurs workflows existants, sans friction ni obstacle, tout en assurant le niveau de supervision adéquat.

Les tests de sécurité renforcés de Snyk pour les pull requests donnent aux développeurs une visibilité précoce et complète sur les tests de sécurité automatisés exécutés sur leurs pull requests, ainsi que la possibilité de demander la validation forcée des tests échoués. De plus, les équipes de sécurité disposent du contrôle nécessaire pour lever les blocages en toute sécurité.

Envie d’essayer ? Ces fonctionnalités sont incluses dans toutes les offres Snyk, y compris l’offre Free.