État de la sécurité des logiciels open source en 2023 selon Snyk : sécurité de la chaîne d’approvisionnement, IA et plus encore

L’IA, les faux positifs et la lente adoption des outils de sécurité restent préoccupants, tandis que l’accélération des correctifs et les progrès en matière de sécurité de la chaîne d’approvisionnement sont encourageants.

L’incident Log4Shell de 2021 a braqué les projecteurs sur la sécurité des logiciels open source, et plus particulièrement sur la sécurité de la chaîne d’approvisionnement. Au cours des 18 mois qui ont suivi, la sécurité des logiciels open source a suscité une attention sans précédent. Des organisations comme l’OpenSSF et AlphaOmega, ainsi que de grandes entreprises technologiques, consacrent des ressources considérables aux outils et à la formation. Mais la sécurité des logiciels open source s’améliore-t-elle vraiment ? Et dans quels domaines les efforts restent-ils insuffisants ? 

Snyk a voulu répondre à cette question dans son dernier rapport, le rapport 2023 sur l’état de la sécurité des logiciels open source. Nous avons interrogé des centaines de professionnels de la technologie et analysé les données anonymisées issues de l’utilisation réelle de notre suite de produits. Ce rapport vise à faire le point sur la situation actuelle et future de la sécurité de la chaîne d’approvisionnement et à aider les organisations à aller de l’avant, alors que le secteur de la chaîne d’approvisionnement logicielle se développe. Voici quelques-unes de nos principales conclusions.

La sécurité de la chaîne d’approvisionnement ne suit pas le rythme du développement

De nombreuses organisations constatent un décalage entre l’innovation en matière de chaîne d’approvisionnement et la sécurité. Si la plupart utilisent des technologies avancées pour la chaîne d’approvisionnement, nous avons constaté que la majorité des personnes interrogées ne sécurisent pas ces processus à l’aide de pratiques telles que les audits continus, la surveillance des dépendances indirectes ou la vérification précoce des scores de sécurité des packages open source. Fait notable, 40 % des répondants n’utilisent toujours pas de technologies de sécurité fondamentales telles que l’analyse de la composition logicielle (SCA) et les tests statiques de sécurité des applications (SAST). 

Alors que les outils de développement open source continuent de se développer et d’attirer l’attention d’acteurs malveillants, les entreprises doivent envisager d’adopter des approches de sécurité de la chaîne d’approvisionnement.

L’automatisation et l’IA ouvrent de nouvelles possibilités et posent de nouveaux défis

L’essor de l’automatisation et de l’IA a un impact évident sur le développement d’applications. Nous constatons des progrès importants dans l’utilisation de ces technologies pour la sécurité. Mais ces technologies émergentes renforcent-elles ou fragilisent-elles la posture de sécurité ? 

Selon notre rapport, ces nouvelles technologies suscitent encore des hésitations, et les avis sont partagés quant à la capacité des outils d’IA à améliorer la sécurité du code. Les résultats concernant l’efficacité de l’automatisation de la sécurité sont également mitigés : 61 % des répondants affirment que l’automatisation a augmenté le nombre de faux positifs. 

Malgré ces avis divergents, la plupart des organisations continuent d’adopter ces nouvelles technologies pour le développement et la sécurité. Seul le temps nous dira quel sera l’impact de l’IA et de l’automatisation sur la sécurité de leur chaîne d’approvisionnement logicielle.

La sécurité de la chaîne d’approvisionnement n’a pas encore adopté l’approche « shift left »

Un principe clé de la sécurité de la chaîne d’approvisionnement consiste à donner aux développeurs les moyens de détecter les vulnérabilités plus tôt dans le cycle de vie du développement logiciel (SDLC). Il s’agit de leur fournir les outils et la formation nécessaires pour coder de manière plus sécurisée et effectuer des analyses plus fréquentes. Ces pratiques améliorent la rapidité et l’efficacité du SDLC, car moins de builds sont bloqués lors des tests pré-déploiement puis renvoyés aux développeurs pour correction. 

Notre enquête révèle que l’approche « shift left » reste elle aussi inachevée. Seuls 40 % des répondants indiquent que leur organisation intègre des outils de sécurité aux IDE des développeurs, et une proportion encore plus faible les utilise localement en ligne de commande. Les outils de build et les dépôts de code sont les emplacements les plus courants pour les outils de sécurité, avec environ 65 % chacun. Ce chiffre montre que les équipes continuent d’intégrer les outils de sécurité de la chaîne d’approvisionnement à des étapes ultérieures du développement, dans les processus de build ou de validation du code, au lieu d’adopter une approche continue de la sécurité du code. 

Pour concrétiser pleinement l’approche proactive « shift left », les développeurs doivent avoir accès aux mêmes outils de sécurité que les équipes DevOps, de sécurité des applications et les autres équipes intervenant en aval. Le chiffre de 40 % n’est pas mauvais, mais il signifie que les outils de sécurité restent minoritaires dans les outils de travail les plus importants des développeurs.

Le nombre de faux positifs générés par l’automatisation est inacceptable

De nombreuses organisations ont déployé des mesures de sécurité automatisées dans leur pipeline de code. Cela a entraîné une hausse des faux positifs dans les alertes de vulnérabilité, ce qui peut nuire à la productivité. Selon l’enquête, 64 % des organisations ont automatisé l’analyse du code, 61 % la gestion des mises à jour logicielles, 59 % les tests (unitaires et de sécurité) et 58 % les pratiques de codage sécurisé (linters, formatage, etc.). Si les outils de sécurité automatisés facilitent la détection des vulnérabilités, ils ont aussi augmenté le taux de faux positifs. 60 % des répondants affirment que l’automatisation a augmenté les faux positifs, contre 30 % qui estiment qu’elle les a réduits. Les faux positifs représentent une part considérable des alertes : 62 % des répondants indiquent qu’au moins 25 % des alertes de vulnérabilité reçues étaient des faux positifs. 35 % des répondants signalent qu’au moins 50 % de leurs alertes étaient des faux positifs.

Cette proportion élevée de faux positifs représente une lourde charge technique pour les équipes de sécurité et de développement et risque de compromettre les avantages de l’automatisation. Les équipes devront chercher à réduire les faux positifs pour réellement améliorer la sécurité de la chaîne d’approvisionnement logicielle. 

L’intensification des réponses en matière de sécurité a ses avantages et ses inconvénients

Plusieurs attaques très médiatisées ont renforcé l’attention portée à la sécurité de la chaîne d’approvisionnement. Les équipes d’ingénierie et de sécurité subissent également la pression d’organismes gouvernementaux, comme le décret exécutif des États-Unis sur l’amélioration de la cybersécurité nationale et le Cyber Resilience Act en préparation dans l’UE. 

Sous l’effet de ces facteurs, plusieurs répondants ont récemment accéléré leurs pratiques de sécurité. Parmi les initiatives engagées : de nouveaux outils, une fréquence accrue d’analyse du code et des formations.

Pourtant, malgré l’obligation fédérale d’établir une nomenclature logicielle (SBOM) instaurée en 2021, seules 42 % des organisations utilisent une SBOM. Et celles qui le font se heurtent à une véritable « tour de Babel » de SBOM. Notre rapport révèle que les organisations utilisent plusieurs outils de développement logiciel, de CI/CD et de sécurité de la chaîne d’approvisionnement pour générer des SBOM. Résultat : les SBOM actuelles sont hétérogènes et peuvent manquer d’interopérabilité, ce qui complique leur analyse pertinente. Ainsi, même si de nombreuses organisations « cochent la case SBOM », elles n’en exploitent toujours pas tout le potentiel.

La sécurité de la chaîne d’approvisionnement s’améliore, mais des efforts restent nécessaires

Dans l’ensemble, le rapport 2023 sur l’état de la sécurité de la chaîne d’approvisionnement logicielle montre que la sécurité de la chaîne d’approvisionnement logicielle s’améliore, mais que des efforts restent nécessaires. Signe que nous avançons dans la bonne direction, notre étude révèle une réduction du délai de correction (TTF) pour tous les niveaux de gravité et dans la plupart des grands écosystèmes open source. En fait, les composants open source sont actuellement corrigés plus rapidement que les logiciels propriétaires. Plusieurs facteurs peuvent expliquer ces tendances positives : l’adoption plus large des outils de sécurité open source tels que la SCA, l’augmentation des financements et des effectifs consacrés à la correction des vulnérabilités critiques de l’open source, ou encore une sensibilisation accrue à la sécurité dans les projets open source. 

En revanche, nous avons également constaté que la surface d’attaque de l’open source reste très étendue, de nombreuses organisations ignorant les vulnérabilités des principaux écosystèmes comme JavaScript, Java et Debian. Par exemple, la vulnérabilité Log4Shell reste sans correctif dans de nombreuses organisations, même 18 mois après sa divulgation.

Nos conclusions montrent également que nous traversons une période de transition, passant d’approches anciennes à de nouvelles méthodes et technologies. En somme, nous sommes sur la bonne voie, mais nous devons poursuivre nos efforts et innover pour réduire les risques liés à l’open source à l’avenir.

Consultez dès aujourd’hui le rapport complet ou découvrez les points clés sur notre page Web interactive.