Catégories
Start-up et applications

Fermer la porte (arrière) des attaques de la chaîne d'approvisionnement

La sécurité est devenue de plus en plus importante dans le processus de développement, car les vulnérabilités de l'année dernière ont causé les 2e, 3e et 7e plus grandes brèches de tous les temps, mesurées par le nombre de personnes touchées.

Cela a mis en évidence le besoin de l’industrie d’une utilisation plus efficace des outils de sécurité dans le développement de logiciels, ainsi que la nécessité d’employer plus tôt des pratiques de sécurité efficaces.

Un autre facteur contribuant à ce besoin croissant est la prédominance des nouvelles attaques telles que les attaques de la chaîne d'approvisionnement logicielle de nouvelle génération qui impliquent le ciblage intentionnel et la compromission de projets open source en amont afin que les attaquants puissent ensuite exploiter les vulnérabilités lorsqu'elles se déplacent inévitablement en aval.

L'année dernière a vu une augmentation de 430% des cyberattaques de nouvelle génération visant à infiltrer activement les chaînes d'approvisionnement de logiciels open source, selon le rapport 2020 State of the Software Supply Chain.

«Les attaquants recherchent toujours la voie de la moindre résistance. Je pense donc qu'ils ont trouvé une faiblesse et un effet amplificateur en s'attaquant aux projets open source et aux développeurs open source », a déclaré Brian Fox, directeur de la technologie chez Sonatype. "Si vous parvenez d'une manière ou d'une autre à compromettre ou à inciter les gens à utiliser une version piratée d'un projet très populaire, vous venez d'amplifier votre base dès le départ. Il n’est pas encore bien compris, en particulier dans le domaine de la sécurité, qu’il s’agit là d’un nouveau défi. »

Ces attaques de nouvelle génération sont possibles pour trois raisons principales. La première est que les projets open source reposent sur les contributions de milliers de développeurs bénévoles, ce qui rend difficile la discrimination entre les membres de la communauté ayant de bonnes ou de mauvaises intentions. Deuxièmement, les projets incorporent jusqu'à des milliers de dépendances qui peuvent contenir des vulnérabilités connues. Enfin, l'éthique de l'open source est fondée sur la «confiance partagée», qui peut créer un environnement fertile pour s'attaquer aux autres utilisateurs, selon le rapport.

Cependant, un outillage approprié, tel que l'utilisation de solutions d'analyse de composition logicielle (SCA), peut améliorer certains de ces problèmes. SCA est le processus d'automatisation de la visibilité des logiciels open source (OSS) à des fins de gestion des risques, de sécurité et de conformité des licences.

Les conteneurs DevOps et Linux, entre autres facteurs, ont entraîné une

augmentation de l’utilisation des logiciels libres par les développeurs, selon Dale Gardner, directeur principal et analyste de l’équipe de sécurité des lieux de travail numériques de Gartner. Plus de 90% des répondants à une enquête Gartner de juillet 2019 indiquent qu'ils utilisent des logiciels open source.

«À l'origine, beaucoup de ces outils (de sécurité) étaient davantage axés sur le côté juridique de l'open source et moins sur les vulnérabilités, mais maintenant, la sécurité retient davantage l'attention», a déclaré Gardner.

L'utilisation du SCA automatisé
En fait, le rapport State of the Software Supply Chain a révélé que les équipes de développement hautement performantes sont 59% plus susceptibles d'utiliser la SCA automatisée et sont presque cinq fois plus susceptibles de mettre à jour avec succès les dépendances et de corriger les vulnérabilités sans rupture. Les équipes sont plus de 26 fois plus rapides à détecter et à corriger les vulnérabilités open source, et déploient des changements de code 15 fois plus fréquemment que leurs pairs.

Le cluster très performant montre une productivité élevée et des résultats de gestion des risques supérieurs peuvent être obtenus simultanément, dissipant l'idée que des pratiques de gestion des risques efficaces se font au détriment de la productivité des développeurs, a poursuivi le rapport.

Le principal différenciateur entre les meilleurs et les moins performants était que les plus performants avaient une structure de gouvernance qui reposait beaucoup plus sur des outils automatisés. Les meilleures équipes étaient 96% plus susceptibles de pouvoir analyser de manière centralisée tous les artefacts déployés pour la sécurité et la conformité des licences.

«Idéalement, un outil devrait également indiquer si les sections de code compromises ou vulnérables – une fois incorporées dans une application – sont exécutées ou exploitables dans la pratique», a écrit Gardner dans son rapport intitulé «Technology Insight for Software Composition Analysis». Il a ajouté: «Cela nécessiterait une coordination avec un test de sécurité d'application statique (SAST) ou un outil de test de sécurité d'application interactif (IAST) capable de fournir une visibilité sur le contrôle et le flux de données au sein de l'application.»

Gardner a ajouté que l'approche la plus courante consiste maintenant à intégrer un grand nombre de ces outils de sécurité dans les IDE et les CLI.

"Si vous demandez aux développeurs" J'ai besoin que vous examiniez cet outil qui comprend la composition logicielle ou quel que soit le cas ", cela a tendance à ne pas arriver", a déclaré Gardner. «L'intégration dans l'EDI élimine une partie des frictions avec d'autres outils de sécurité et c'est aussi une question d'économie. Si je peux repérer le problème au moment même où le développeur introduit quelque chose dans le code, il sera alors beaucoup moins cher et plus rapide de le résoudre que si c'était le cas. C’est ainsi que travaillent de nombreux développeurs. »

Au-delà de la conformité
L'utilisation de SCA pour examiner les licences et comprendre les vulnérabilités avec des packages particuliers est déjà des cas d'utilisation importants des solutions SCA, mais ce n'est pas tout ce dont elles sont capables, selon Gardner.

«Les domaines que je compte développer seront liés à la compréhension de la provenance d’un colis particulier: d’où vient-il, qui est impliqué dans sa construction et à quelle fréquence il est entretenu. C'est la partie que je vois le plus grandir et même qui est encore relativement naissante », a déclaré Gardner.

La vue globale fournie par certaines solutions SCA n'est pas disponible dans de nombreux outils qui reposent uniquement sur l'analyse des dépôts publics.

S'appuyer sur les dépôts publics pour trouver des vulnérabilités – comme le font encore de nombreux outils de sécurité – ne suffit plus, selon Fox de Sonatype. Parfois, les problèmes ne sont pas enregistrés dans la base de données nationale sur les vulnérabilités (NVD) et même lorsque ces informations sont signalées, il y a souvent un délai de deux semaines ou plus avant qu'elles ne deviennent publiques.

"Vous vous retrouvez donc avec ces cas où les vulnérabilités sont largement connues parce que quelqu'un a blogué à ce sujet, et pourtant si vous allez sur le NVD, il n'est pas encore publié, donc il y a un décalage énorme", a déclaré Fox.

Au lieu de cela, une sécurité efficace nécessite d'aller un peu plus loin dans l'inspection de l'application construite elle-même afin d'empreinte digitale de ce qui se trouve réellement à l'intérieur d'une application. Cela peut être fait grâce à une empreinte binaire avancée, selon Fox.

La technologie essaie de fonctionner de manière déterministe à rebours à partir du produit final pour comprendre ce qu'il contient réellement.

«C’est comme si je vous tendais une recette et si vous la regardiez, vous pourriez juger qu’une tarte ou un gâteau peut être mangé sans danger parce que la recette ne dit pas insérer du poison, non? C’est ce que font ces outils. Ils disent, eh bien, ça dit ici sucre, ça ne dit pas sucre contaminé, et il n'y a pas de poison dedans. Donc, votre gâteau est sûr à manger », a déclaré Fox. «Par rapport à ce que nous faisons ici, nous inspectons en fait le contenu du gâteau cuit au four et allons, attendez une minute. Il y a une chromatographie qui montre qu'il y a réellement du poison ici, même si la recette ne l'exigeait pas et c'est en quelque sorte la différence fondamentale. "

Il y a également eu un changement majeur par rapport au positionnement traditionnel de la sécurité des applications.

Développement du ciblage
Dans de nombreuses attaques qui se produisent actuellement, les développeurs et l'infrastructure de développement sont la cible. Et bien que les organisations s'efforcent tellement de s'assurer que le produit final lui-même est sûr avant qu'il ne soit acheminé aux clients et au serveur, dans le nouveau monde, cela n'a pas d'importance, selon Fox. Ce sont peut-être les développeurs qui ont été compromis pendant tout ce temps, alors que les choses étaient siphonnées hors de l'infrastructure de développement.

«Nous avons vu des attaques qui volaient des clés SSH, des certificats ou des informations d'identification AWS et transformaient des fermes de construction en cryptomineurs, ce qui n'a rien à voir avec le produit final», a déclaré Fox. «Dans le monde DevOps, les gens parlent beaucoup de Deming et de la façon dont il a contribué à faire du Japon des voitures meilleures et plus efficaces pour moins d'argent en se concentrant sur les principes clés des chaînes d'approvisionnement. Bien devinez quoi. Deming n’essayait pas de se protéger contre une attaque de sabotage de l’usine elle-même. Ces processus sont conçus pour fabriquer de meilleures voitures et non pour rendre l'usine plus sûre. Et c'est le genre de situation dans laquelle nous nous trouvons avec ces attaques en amont. "

Désormais, des outils de sécurité efficaces peuvent capturer et automatiser les exigences pour aider les développeurs à prendre des décisions à l'avance et à leur fournir des informations et du contexte lorsqu'ils choisissent une dépendance, et non après, a ajouté Fox.

En outre, lorsque l’outillage reconnaît qu’un composant a une vulnérabilité nouvellement révélée, il peut reconnaître qu’il n’est pas nécessairement approprié d’arrêter toute l’équipe et d’interrompre toutes les versions, car tout le monde n’est pas chargé de corriger chaque vulnérabilité. Au lieu de cela, il informera un ou deux développeurs expérimentés du problème.

«C'est une combinaison d'essayer de comprendre ce qu'il faut pour aider les développeurs à faire ces choses plus rapidement, mais aussi d'être en mesure de le faire avec la vue descendante de l'entreprise et de capturer cette politique – non pas pour être Big Brother-y – mais pour capturer la politique de sorte que lorsque vous êtes le développeur, vous obtenez cette information instantanée sur ce qui se passe », a déclaré Fox.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *