Renforcer la sécurité de la chaîne d'approvisionnement logicielle : idées du sommet

Ces dernières années, on a vu une montée des cyberattaques visant des systèmes logiciels, surtout ceux qui sont moins sécurisés. Ces attaques peuvent causer des dommages sérieux aux entreprises et organisations. Deux exemples marquants sont les incidents SolarWinds et log4j, qui ont touché des milliers de clients. Le gouvernement américain et les leaders du secteur se concentrent maintenant sur l'amélioration de la sécurité des chaînes d'approvisionnement en logiciels. Cet article résume un récent sommet où des experts ont discuté de différents aspects de la sécurité des chaînes d'approvisionnement en logiciels.

#Aperçu du Sommet

Le 30 septembre 2022, un sommet a eu lieu avec 19 professionnels du secteur provenant de 17 entreprises différentes. L'objectif du sommet était de partager des expériences et d'identifier des défis liés à la sécurité des chaînes d'approvisionnement en logiciels. Les discussions se sont tenues en petit groupe pour encourager une communication ouverte. Les participants comprenaient des représentants de grandes entreprises, de moyennes sociétés et d'une fondation de logiciels.

#Format du Sommet

Le sommet comportait une présentation principale et six tables rondes. Avant l'événement, les participants ont rempli un sondage pour choisir les sujets de discussion. Chaque table ronde durait 45 minutes, en commençant par quatre intervenants qui faisaient des déclarations courtes. Le reste du temps était consacré à une discussion de groupe. Des notes ont été prises pendant les discussions, qui ont ensuite été résumées dans cet article.

#Décret Exécutif

Un sujet clé de discussion était le Décret Exécutif 14028, émis le 12 mai 2021. Ce décret exige que les organisations fournissant des logiciels critiques au gouvernement américain améliorent la sécurité de leurs logiciels et de leur chaîne d'approvisionnement. Beaucoup d'organisations devront changer leurs processus internes pour se conformer à ces exigences.

Certains participants au sommet avaient déjà rencontré des agences gouvernementales pour aider à façonner le décret et clarifier les exigences. Bien que certaines organisations suivent déjà des pratiques conformes au décret, d'autres ont exprimé des inquiétudes sur la conformité, en particulier les petites entreprises qui peuvent manquer de ressources. Des discussions ont eu lieu sur la manière dont le décret pourrait obliger les développeurs à ajuster leurs habitudes de travail et les processus qu'ils suivent.

#Questions Ouvertes

Une question clé soulevée lors de ce panel était les conséquences de la non-conformité au décret. Les participants se demandaient si le décret créerait des problèmes juridiques pour les organisations qui ne s'y conforment pas.

#Facture de Matériaux Logiciels (SBOM)

Un autre sujet important abordé était la Facture de Matériaux Logiciels (SBOM). Une SBOM est essentiellement une liste des composants qui composent un produit logiciel. Elle aide les organisations à garder une trace des éléments tiers et à gérer les vulnérabilités. Selon le Décret Exécutif, les entreprises vendant des logiciels au gouvernement fédéral doivent fournir une SBOM complète.

#Avantages pour les Producteurs et les Consommateurs

Les discussions se sont concentrées sur les avantages des SBOM pour les producteurs et les consommateurs de logiciels. Les producteurs peuvent établir la confiance avec les clients en fournissant des informations claires sur leurs produits. Les consommateurs en profitent en obtenant des informations sur les risques potentiels liés aux vulnérabilités.

Les participants ont souligné l'importance d'avoir des outils robustes pour gérer les SBOM. Bien que la production de SBOM soit devenue plus avancée, la consommation efficace reste un défi. Certains participants ont exprimé des doutes sur la fiabilité des SBOM de première génération et la nécessité de vérifications régulières.

#Questions Ouvertes

Certaines questions non résolues incluaient la nécessité de mettre à jour les gestionnaires de paquets pour produire des SBOM et ce que le gouvernement prévoit de faire avec les SBOM qu'il reçoit.

#Dépendances vulnérables

Les logiciels reposent souvent sur des composants tiers appelés dépendances pour ajouter des fonctionnalités. Cependant, ces dépendances peuvent introduire de la complexité et des vulnérabilités potentielles. Lorsqu'un problème de sécurité survient dans une dépendance, il est crucial pour les organisations de se mettre à jour rapidement vers la dernière version.

#Processus et Défis

Les participants au sommet ont discuté de diverses méthodes pour identifier et traiter les vulnérabilités dans les dépendances. Des outils existent pour scanner ces vulnérabilités, mais le volume peut être écrasant. Une fois les vulnérabilités identifiées, les praticiens ont souvent du mal à suivre les mises à jour, car de nouveaux problèmes apparaissent fréquemment.

Bien que certains outils puissent corriger automatiquement les dépendances, de nombreuses organisations trouvent cette approche peu pratique. Les développeurs doivent passer en revue manuellement ces mises à jour, ce qui peut entraîner des retards. Il y a aussi souvent de la confusion sur la manière de déterminer la bonne version à utiliser.

#Questions Ouvertes

Les participants ont considéré des questions sur les meilleures pratiques pour gérer les mises à jour des dépendances, s'il fallait appliquer différents niveaux de vérification pour les mises à jour, et la meilleure façon d'attribuer la responsabilité de la gestion des dépendances.

#Détection des Commits Malveillants

Des acteurs malveillants peuvent injecter des changements nuisibles dans des projets logiciels par le biais de commits non autorisés. Repérer ces changements malveillants est difficile, car les attaquants essaient souvent de dissimuler leurs actions.

#Stratégies de Détection

Les participants ont discuté des moyens d'identifier un comportement suspect en examinant les activités d'un committer. Des motifs de changements importants ou inhabituels peuvent signaler des problèmes potentiels. L'apprentissage automatique pourrait aider à créer des outils pour détecter un comportement malveillant, bien que l'analyse de ce type d'activité puisse être délicate.

Plusieurs praticiens ont souligné le défi de faire la distinction entre des erreurs innocentes et un code intentionnellement nuisible. De nouveaux cadres de sécurité sont en cours d'introduction, nécessitant une plus grande vigilance à divers stades du processus de développement logiciel.

#Questions Ouvertes

Les questions clés soulevées incluaient comment équilibrer les mesures de sécurité avec les besoins d'efficacité des développeurs, surtout en cas de situations urgentes.

#Processes de Build et de Déploiement Sécurisés

Des pratiques de build et de déploiement sécurisées sont cruciales pour garantir que les logiciels sont développés et lancés de manière sécurisée. Ces pratiques incluent la création d'environnements sécurisés et le suivi précis des modifications.

#Pratiques Actuelles

La plupart des participants ont déclaré se sentir à l'aise avec le processus de déploiement mais ont exprimé des inquiétudes concernant l'aspect build. Beaucoup utilisent des outils de journalisation et de surveillance pour suivre les activités et garantir la transparence. Certaines organisations travaillent avec des auditeurs tiers pour une sécurité accrue.

Le sommet a mis en évidence la nécessité d'une meilleure séparation des droits d'accès pour maintenir la sécurité. Bien qu'il existe une prise de conscience de divers cadres comme SLSA pour des conseils, les participants ont indiqué qu'ils avaient encore besoin de plus de temps pour leur mise en œuvre.

#Builds Reproductibles

Les builds reproductibles garantissent que le logiciel peut être construit de manière cohérente, de sorte que le produit final soit identique à chaque fois. Cette pratique aide à vérifier qu'un build n'a pas été altéré.

#Défis à l'Implémentation

Bien que de nombreux praticiens soutiennent l'idée de builds reproductibles, ils ont également souligné les obstacles à atteindre cet objectif. Dans certains cas, les langages de programmation peuvent compliquer le processus en raison de l'aléatoire dans les données. D'autres ont soulevé des préoccupations concernant l'impact environnemental de la construction de logiciels plusieurs fois.

#Questions Ouvertes

Des questions demeurent sur les alternatives aux builds reproductibles et comment elles peuvent être utilisées pour identifier toute altération.

#Normes et Directives

Diverses normes et cadres existent pour guider les organisations dans l'amélioration de la sécurité des chaînes d'approvisionnement en logiciels. Un cadre majeur est SLSA, qui fournit une liste de contrôles pour prévenir la falsification et améliorer l'intégrité des logiciels.

#Adoption des Normes

La plupart des participants au sommet s'efforcent d'atteindre des niveaux de conformité plus élevés avec le cadre SLSA. Cependant, ils ont également noté la nécessité d'une guidance plus claire sur certains aspects et un soutien pour l'implémentation de ces normes.

Des préoccupations ont été soulevées quant à la capacité de prouver la conformité à ces normes, surtout pour les petites organisations. Certains participants ont exprimé des doutes sur la capacité du gouvernement à établir les bonnes normes.

#Conclusion

Le sommet a fourni des perspectives précieuses sur l'état actuel de la sécurité des chaînes d'approvisionnement en logiciels. Les participants ont exprimé leurs préoccupations concernant la conformité au Décret Exécutif, les défis de la gestion des dépendances, et les questions entourant les SBOM. Il y avait aussi une reconnaissance partagée de l'importance de pratiques de sécurité solides pour détecter des actions malveillantes et garantir des builds et des déploiements sécurisés. Les discussions ont souligné la nécessité d'une collaboration continue et le développement de meilleurs outils et cadres dans le domaine de la sécurité des logiciels.