Assurance continue : une pratique intégrale pour la sécurité de la chaîne d'approvisionnement logicielle

Ce est le deuxième d'une série d'articles examinant les nouvelles directives NIST SP 800-218. Le premier article peut être trouvé ici.

Assurance continue :
Une pratique intégrale pour la sécurité de la chaîne d'approvisionnement logicielle

Comme nous l'avons évoqué dans notre article précédent, les directives établies par l'Institut national américain des normes et de la technologie (NIST) modifieront considérablement la manière dont les produits et services logiciels sont fournis au gouvernement américain. 

Plus précisément, NISTSP 800-218 établit un ensemble de pratiques de développement logiciel sécurisées de haut niveau qui doivent être intégrées dans chaque cycle de vie de développement logiciel (SDLC). L'intégration de ces pratiques tout au long de la chaîne d'approvisionnement en logiciels devrait promouvoir des produits et services plus sécurisés destinés non seulement au gouvernement américain, mais, à terme, à tous les secteurs et dans le monde entier. 

Dans cet article, nous examinons le rôle essentiel de l’assurance continue (AC) pour répondre à ces nouvelles exigences. 

Présentation : Qu'est-ce que l'assurance continue et comment fonctionne-t-elle ? 

CA est un concept et un ensemble de solutions en devenir, complémentaires aux concepts déjà familiers de la discipline DevOps d'intégration continue, de développement et de tests. CA collecte de manière granulaire des preuves sur tous les événements du cycle de vie de développement, y compris la création et le déploiement du produit, susceptibles d'affecter la sécurité du produit logiciel final. Il s'agit d'un moyen pour les consommateurs de logiciels (tels que les utilisateurs, les acheteurs et autres parties prenantes au risque) de contrôler les risques liés aux produits qu'ils utilisent. 

Aujourd'hui, les entreprises appliquent une myriade d'outils de sécurité pour améliorer la sécurité des produits logiciels qu'elles développent. Cependant, ils utilisent rarement une politique globale pour établir la norme pour une utilisation cohérente de ces outils. De plus, si les consommateurs de produits logiciels appartiennent à une autre organisation, ils ne disposent d'aucune information ni des outils nécessaires pour fixer la barre en matière de risques. En un mot, c'est là le point mort de la chaîne d'approvisionnement logicielle que CA vise à dissiper. 

Le résultat immédiat de CA est un moyen de garantir que les produits logiciels n'ont pas été falsifiés et que des tests critiques liés à la sécurité ont été effectués pendant le développement, mais il y a encore plus à gagner.

Pour contrecarrer la falsification par des attaquants ou la dissimulation par des fournisseurs de composants sous le capot d'origine douteuse, par exemple en provenance de pays interdits, CA transforme les preuves collectées en une attestation infalsifiable en signant les informations de manière cryptographique et en les stockant dans un magasin immuable. un environnement isolé et sécurisé. 

En rendant les preuves collectées lisibles par machine, un moteur de politique peut valider en continu les normes ou règles définies par la partie prenante du risque pour chaque version ou mise à jour du produit. De cette façon, les parties prenantes peuvent être assurées de la conformité d'un produit à ses normes de sécurité. 

Conceptuellement, l'utilisation de la méthodologie CA améliore également la qualité du produit. En contrôlant la norme de base pour la révision du code et les tests de sécurité avec une politique centrale pour les pipelines d'un produit particulier, les incohérences et les modifications ponctuelles apportées aux processus ordonnés seraient éliminées.

Pourquoi continu ?

Les configurations de sécurité dans le processus de développement ne sont pas nouvelles. Par exemple, vous avez peut-être déjà établi qu'aucun binaire ne sera mis en production sans analyse des vulnérabilités. 

Aujourd’hui, les cycles de livraison de logiciels sont de plus en plus courts. En conséquence, des raccourcis pourraient être rognés. La révision du code peut être ignorée, ou des tests de sécurité ou des procédures importantes peuvent ne pas être effectués. De plus, de nouveaux CVE et exploits sont constamment signalés et de nouvelles versions de composants sont constamment publiées. 

Tous ces facteurs combinés nous obligent à tester continuellement les composants par rapport à la norme de sécurité définie pour vérifier que les processus utilisés sont toujours conformes à la politique de sécurité. 

Les politiques de sécurité sont déterminées par le détenteur du risque. Voici quelques exemples de règles politiques qui pourraient être utilisées : 

• Autoriser l'utilisation de packages open source provenant d'une liste approuvée uniquement
• Exigez deux réviseurs pour chaque demande d'extraction.
• Vérifiez que tous les composants propriétaires de l'artefact final peuvent être retracés jusqu'aux dépôts de contrôle de source.

Relever la barre de sécurité des logiciels

Les attaques contre la chaîne d'approvisionnement logicielle modifient le comportement attendu des composants logiciels. Aujourd'hui, ces attaques reposent sur le manque de capacité des consommateurs et des producteurs de logiciels à vérifier l'intégrité des composants logiciels. 

Cependant, en signant des preuves à chaque étape du cycle de vie du développement (des dépendances open source jusqu'au produit final) et en comparant continuellement ces preuves avec ce qui est attendu, les attaquants seront confrontés à de plus grandes difficultés lorsqu'ils tenteront de falsifier des fichiers, des outils ou des fichiers. comportement attendu de votre pipeline CI/CD.     

Collecte de preuves : exemples et recommandations

Voici quelques exemples de preuves qui peuvent être collectées tout au long du SDLC :

Et voici les types de politiques qui peuvent être utilisées, en utilisant ces preuves :

L’avenir de l’assurance continue du code

Dans le cadre de développement de logiciels sécurisés de février 2022 (SSDF), le NIST suggère que la mise en œuvre d'outils de sécurité tout au long du processus de développement devrait s'appuyer en grande partie sur l'automatisation. Notre approche de l’assurance continue est conforme à cette recommandation. 

Même si vous êtes sûr que toutes les étapes et mesures de sécurité ont été correctement configurées, vous devez toujours fournir les moyens d'assurer aux clients et aux fournisseurs que votre politique de sécurité a été appliquée de manière cohérente et continue. Toutes les parties prenantes, producteurs de logiciels (développeurs ou fournisseurs) et consommateurs (utilisateurs ou acheteurs) devraient être en mesure d'examiner et de vérifier en permanence et automatiquement les preuves de chaque maillon de la chaîne d'approvisionnement des logiciels pour s'assurer que leurs propres critères de sécurité sont respectés. 

La confiance dans la chaîne d’approvisionnement en logiciels est actuellement faible, ce qui constitue une source constante d’inquiétude pour toutes les parties prenantes. Augmenter la visibilité sur les mesures de sécurité qui ont été mises en œuvre et fournir la preuve de l'assurance continue du code font partie intégrante du rétablissement de la confiance dans la chaîne d'approvisionnement logicielle et de la production de produits vérifiables plus sécurisés.