Sonatype présente la gestion des dépendances nouvelle génération | Communiqué de presse

Qualys et Nexus Lifecycle

Placer la sécurité au cœur du développement

Stratégies visant à éliminer les risques liés à l'open source lorsqu'ils sont évitables : entretien avec Andrew Wild, ancien responsable de la sécurité chez Qualys

Lors de la conférence Gartner Security & Risk Management Summit de juin 2014, Wayne Jackson, PDG de Sonatype, a réuni une équipe de professionnels de la sécurité afin d'aborder les stratégies visant à éliminer les risques liés à l'open source lorsqu'ils sont évitables. Andrew Wild, ancien responsable de la sécurité chez Qualys, a partagé ses idées et ses expériences sur la création d'un cycle de développement logiciel à la fois sécurisé et efficace, qui permettait aussi d'éviter les risques liés à l'open source. Voici des extraits de cette discussion.

Jackson : L'enquête conduite par Sonatype en 2014 sur la sécurité des applications et des développements open source a révélé que les applications constituaient le vecteur d'attaque le plus souvent ciblé. Pourtant, nous consacrons relativement peu de temps et d'argent à la sécurisation de ce vecteur d'attaque. À votre avis, pourquoi en est-il ainsi et comment les choses pourraient-elles changer ?

Wild : Je pense que la situation s'explique en grande partie par l'histoire de la sécurité de l'information dans les entreprises. Au fil des ans, et après de nombreux efforts, la sécurité de l'information s'est intégrée à l'informatique et à l'entreprise. Mais nombre d'entreprises n'ont pas intégré la sécurité de l'information dans le travail des ingénieurs du développement. Par conséquent, les vulnérabilités ne sont pas visibles. Seules les exploitations le sont.

La sécurité de l'information attire désormais l'attention, mais soit on manque d'outils, soit ces outils ne sont tout simplement pas déployés dans l'entreprise. La sécurité de l'information n'est pas prise en compte par l'équipe d'ingénieurs ; elle n'est donc pas incluse dans le cycle de développement logiciel. Et les ingénieurs préfèrent s'en tenir à ce qu'ils maîtrisent le mieux : budgétiser les rewalls et la sécurité des points de terminaison.

Jackson : Il est encore surprenant de constater combien de personnes occupant de hautes fonctions n'ont aucune idée de l'étendue de leur utilisation de l'open source et s'ils sont vulnérables ou non.

Wild : Des progrès ont été réalisés en termes de connaissances et de politiques. Aujourd'hui, il n'est pas rare de lire dans les déclarations publiques des sociétés cotées en bourse que l'utilisation de logiciels open source constitue un facteur de risque et que l'octroi de licences en subit les conséquences. La façon dont ce risque est énoncé et divulgué, c'est-à-dire la façon dont il est vraiment géré ou limité en interne, est une question complètement différente, à mon sens. Mais cet aspect commence à s'imposer de plus en plus. On a conscience qu'il s'agit d'un risque qui doit être géré. À mon avis, dans nombre d'entreprises, ces risques s'ajoutent à d'autres risques, et ils ne bénéficient peut-être pas de l'attention qu'ils méritent.  

« Nous souhaitions fournir à nos développeurs les outils leur permettant de prendre des décisions éclairées lors de la sélection de composants open source. »
— Directeur de la sécurité, Qualys

Jackson : Les gens réalisent que leur infrastructure repose sur l'open source. Les politiques qui dépendent d'actions humaines et qui relèvent de méthodologies plus anciennes – établir des listes blanches et des listes noires, demander des autorisations, etc. – s'avèrent insuffisantes, car l'open source utilisé est trop complexe.

Wild : L'une de mes priorités consistait à accroître la visibilité. Chez Qualys, nous disposons d'un cycle de développement logiciel défini. Nous adoptons une philosophie de développement agile, mais il existait un décalage entre la visibilité dont bénéficiait l'équipe en charge de la sécurité avec l'équipe des développeurs. Vous avez évoqué le fait que les développeurs n'effectuent pas de suivi ou ne disposent pas de connaissances suffisantes. Pourquoi en serait-il autrement ? Ils conçoivent un logiciel et celui-ci passe les tests d'assurance qualité. Le groupe des opérations est généralement celui qui gère les vulnérabilités de façon continue. L'équipe des opérations reçoit un code assemblé qu'elle doit exécuter. Elle ne dispose pas nécessairement d'une visibilité détaillée de tous les composants qui constituent ce système. Cette situation crée de potentielles déconnexions. Par conséquent, accroître la visibilité dans le processus de build – et identifier les composants open source qui vont être utilisés avant que le processus de build ne soit terminé – constituait à mon avis un élément essentiel qui augmenterait considérablement notre capacité à développer un code sûr.

Jackson : Vous créez un code qui assure également la sécurité des autres.

Wild : Tout à fait ! Il est donc primordial que nous le fassions correctement. Ce n'est pas parce que vous achetez un produit de sécurité que les gens qui l'ont créé sont calés en sécurité, du moins au niveau du code. Il est très complexe de faire les choses correctement, sans tomber dans une apparente sécurité, simplement parce qu'un produit comporte le terme de « sécurité ».

Jackson : Toyota a mis en place un processus qui lui permet d'optimiser sa chaîne d'approvisionnement en tâchant de produire davantage de produits, plus rapidement, avec un degré supérieur de prévisibilité et d'efficacité dans le temps. Quand vous dites que la première étape consiste à disposer de connaissances, on voit que la philosophie de Toyota à l'égard de sa chaîne d'approvisionnement consiste à doter les employés de connaissances afin qu'ils soient en mesure de prendre des décisions en temps réel. Des garde-fous sont en place, de sorte que la prévisibilité est préservée et optimisée dans le temps.

Wild : Dans le secteur privé, la gestion des risques liés aux tiers évolue très rapidement, mais peut-être pas aussi rapidement qu'elle le devrait. Toutefois, au cours des trois ans que j'ai passés chez Qualys, j'ai noté d'importants changements dans le volume et la complexité des questions que posent les clients sur le programme de sécurité de Qualys. Les clients souhaitent connaître le cycle de développement des logiciels, son fonctionnement, les informations et les contrôles dont nous disposons, et notre utilisation des logiciels open source. On peut donc dire que ces interrogations commencent à faire partie de la procédure d'achat et que de tels changements vont avoir des effets, au moins dans le secteur privé. Dans quelle mesure ces changements se traduisent-ils par de réelles améliorations de la sécurité ? Cela reste à définir. Mais je pense que la gestion des risques liés aux tiers évolue, et qu'elle génère des efforts concertés et un élan.

« Une bill of materials, qu'il s'agisse des composants open source ou des composants internes, fait partie de la stratégie globale des grands projets de logiciels. Elle permet de disposer de composants fiables et sécurisés, qui ont été contrôlés et vérifiés comme étant corrects et acceptables. La réutilisation de ces composants est un élément clé de la stratégie. »

Sur le plan commercial, nous avons toujours plaisanté en disant qu'après Enron, nous avions enfin trouvé la raison pour laquelle la qualité doit primer. Cette raison, c'est la prison ! Si les gens risquent la prison, la qualité devient leur religion. Je pense qu'il en va de même dans le domaine de la sécurité. Prenons l'exemple de la société Target, dont je sais que tout le monde parle dans cette conférence puisque c'est la première fois qu'un PDG a vu rouge à cause d'un piratage informatique. Pour moi, cette histoire va avoir des répercussions énormes sur le plan commercial ne serait-ce qu'en termes de visibilité et de prise de conscience à l'égard de ce genre de choses. Sans diligence ni gouvernance, vous vous exposez à des problèmes.

En ce qui concerne la réglementation, la politique et la gouvernance, il est difficile d'établir des règles et d'amener les gens à les suivre, mais il est aussi difficile de mettre ces règles en application. Nous avons constaté que certains contrats stipulaient : « Utiliser la méthode agile lors de la conception ». Le site Healthcare.gov a été conçu selon la méthode agile. Cependant, les personnes qui gèrent le site et qui travaillent pour le gouvernement ignorent de quoi il est question et comment faire appliquer cette méthode. Il nous faut donc former les membres du gouvernement en charge de l'acquisition, de la gestion de projets et de la gestion de programmes afin qu'ils sachent quelles questions poser et comment s'assurer que ce qu'ils demandent est réellement fait, car bien souvent, ce n'est pas le cas.

Les prestataires de services font pression sur le gouvernement pour qu'il accepte des choses qui ne correspondent pas à ce qu'il souhaitait, pour la simple et bonne raison que le gouvernement n'est pas en mesure de vérifier ces aspects. C'est donc un élément à ne pas négliger au moment de légiférer.

Jackson : Pourquoi ne pas intégrer la sécurité de l'open source dans la culture du processus de développement ? Nous avons commencé à encourager les gens à réfléchir davantage à la création d'une culture où les développeurs pourraient simplement prendre de meilleures décisions.

Wild : Nombre d'entreprises fournissent aux développeurs des directives relatives à la sécurité du codage. Si les développeurs suivent ces directives et qu'elles sont maintenues à jour, c'est parfait. Avec un peu de chance, une telle approche permet d'assurer la sécurité du code qui est développé en interne. Mais ces mêmes entreprises oublient un élément important : comment le développeur parvient-il à sélectionner les composants sûrs ? Comment détermine-t-il si tel ou tel composant est vulnérable ? De quelles ressources dispose-t-il ? Est-il obligé ou invité à vérifier pour s'en assurer ? Se voit-il fournir des directives lui permettant de sélectionner un composant ? Il est probable qu'il choisisse un composant car un ami plus expérimenté lui a dit que c'est le meilleur composant, qu'il marche, qu'il est rapide. Alors le développeur fait avec. Nous devons fournir à nos développeurs les outils leur permettant de prendre des décisions éclairées lors de la sélection de composants open source. Lorsqu'un développeur est à la recherche d'un composant, la sécurité de ce composant devrait figurer parmi les critères à prendre en compte, aux côtés d'autres critères comme l'assistance, la compréhension, la documentation, la réactivité et la performance.

Jackson : Envisagez-vous le DevOps et le Continuous Delivery chez Qualys ?

Wild : Nous basculons assurément vers le DevOps. Quand on parle de modèle de déploiement dans le cloud, où les mises à jour sont déployées en quasi permanence, c'est la voie à suivre. Cette approche va améliorer notre efficacité et notre réactivité. Nous allons injecter davantage de sécurité dans ce processus et je pense que c'est ce qu'apporte le DevOps : l'occasion pour les professionnels de la sécurité de véritablement s'impliquer dans la communauté DevOps et de travailler en étroite collaboration avec elle... À mon avis, il faut prendre part à ce processus et c'est ce que nous faisons chez Qualys.

CONTACTER L'ÉQUIPE COMMERCIALE

Prêt à essayer les produits Nexus ?

Sonatype, une meilleure façon de construire