Temps de lecture : 5 minutes
Marc Hermeling de CodeSecure explique que les équipes qui construisent des produits innovants s'appuient sur des géants. En effet, lorsqu’une équipe développe sur les dernières cartes de NXP, ST Micro, Texas Instruments ou d'autres, elle utilise généralement leur Kit de Développement Logiciel (SDK) comme base pour le code. Ces SDK offrent de nombreux contenus relatifs à la mise en route des cartes, à la gestion des appareils, aux graphiques, à la gestion de l'énergie, à la communication, au Bluetooth, au WiFi, et bien plus encore. De plus, les dernières générations de ces cartes intègrent des fonctions d’IA.
De même, lorsqu’un logiciel est développé sur des téléphones Android ou Apple, le SDK de ces plateformes est utilisé pour connecter le logiciel. Même si une équipe intègre des caméras pour la vision par ordinateur, elle disposera également d'un SDK adapté.
Une couche de complexité supplémentaire
L’utilisation des SDK permet aux équipes d'accélérer leur mise sur le marché. Cependant, elle introduit aussi des défis pour le respect des nouvelles réglementations. En Europe, par exemple, la loi sur la résilience numérique exige des organisations qu'elles génèrent, maintiennent et fournissent une SBOM (Software Bill of Materials) pour tous les logiciels des produits qu'elles commercialisent dans l'UE. Aux États-Unis, les SBOM sont mandatés dans le cadre des processus d'acquisition du gouvernement fédéral et s’étendent peu à peu à d’autres secteurs. La Food and Drug Administration (FDA) américaine exige également une SBOM pour les dispositifs médicaux dans le cadre de leur approbation pré-commerciale.
Il est fréquent que les organisations ne reçoivent pas de SBOM avec leur SDK. Certains fournisseurs en proposent, mais la majorité n’en fournit pas. Par ailleurs, une grande partie des SDK est souvent distribuée uniquement sous forme binaire. Si le code source n’est pas accessible, la SBOM ne l'est pas non plus.
Alors, comment répondre aux besoins réglementaires en matière de visibilité dans le SDK à travers une SBOM ? Même en cas de réception d'une SBOM du fournisseur, celle-ci couvre généralement l’ensemble du SDK, alors que l'équipe n’en utilise souvent qu’une partie.
Il est fréquent que les organisations ne reçoivent pas de SBOM avec leur SDK. Certains fournisseurs en proposent, mais la majorité n’en fournit pas. Par ailleurs, une grande partie des SDK est souvent distribuée uniquement sous forme binaire. Si le code source n’est pas accessible, la SBOM ne l'est pas non plus.
Alors, comment répondre aux besoins réglementaires en matière de visibilité dans le SDK à travers une SBOM ? Même en cas de réception d'une SBOM du fournisseur, celle-ci couvre généralement l’ensemble du SDK, alors que l'équipe n’en utilise souvent qu’une partie.
Voir à travers votre SDK
C’est ici qu’intervient l’analyse de composition binaire (BCA). Lorsque le produit est scanné à l'aide d'un outil BCA, comme CodeSentry de CodeSecure, une SBOM précise et spécifiquement adaptée à ce produit est générée, couvrant uniquement la partie du SDK utilisée. Plutôt que d'attendre la fin du cycle de développement, ce qui est souvent trop tard, les équipes peuvent générer une SBOM à des moments pertinents durant le cycle de développement logiciel. La SBOM inclut aussi des informations sur les licences, garantissant que le produit est conforme aux exigences de licence applicables et ne contient pas de licences virales.
Exemple de données SDK dans les SBOM
Générer une SBOM à partir du binaire du produit permet un gain de temps notable. Avec les bons outils BCA, cela devient rapide et facile à réaliser aux étapes nécessaires du développement, avec un retour d’information immédiat.
Récemment, Marc Hermeling a collaboré avec un conglomérat mondial qui utilise CodeSentry dans son processus d’examen de sécurité. Une de leurs équipes préparait le lancement d'un nouveau produit. Le scan du produit avec CodeSentry a révélé quelques problèmes majeurs, notamment un nombre élevé de vulnérabilités connues dû à l’utilisation de composants open source obsolètes. Un autre problème identifié concernait la présence de composants sous licences GPL. En analysant ces dépendances, il est apparu que ces problématiques provenaient d’un SDK de fournisseur plus ancien. L’équipe a alors pris deux mesures : elle a d’abord réduit le champ d’application pour publier les fonctionnalités critiques, puis elle a travaillé avec le fournisseur pour mettre à niveau les composants open source.
Cet exemple montre l'importance de scanner les kits d'outils, tout comme pour n'importe quel code tiers.
En résumé, pour les équipes qui construisent leurs produits à partir de SDK tiers et qui sont soumises à des exigences de SBOM, l'analyse de composition binaire est essentielle pour assurer la conformité réglementaire. Aujourd'hui, cela s’applique aux systèmes développés pour le gouvernement fédéral américain, aux dispositifs médicaux, à l’automobile et autres infrastructures critiques, ainsi qu'au marché européen plus large.
Récemment, Marc Hermeling a collaboré avec un conglomérat mondial qui utilise CodeSentry dans son processus d’examen de sécurité. Une de leurs équipes préparait le lancement d'un nouveau produit. Le scan du produit avec CodeSentry a révélé quelques problèmes majeurs, notamment un nombre élevé de vulnérabilités connues dû à l’utilisation de composants open source obsolètes. Un autre problème identifié concernait la présence de composants sous licences GPL. En analysant ces dépendances, il est apparu que ces problématiques provenaient d’un SDK de fournisseur plus ancien. L’équipe a alors pris deux mesures : elle a d’abord réduit le champ d’application pour publier les fonctionnalités critiques, puis elle a travaillé avec le fournisseur pour mettre à niveau les composants open source.
Cet exemple montre l'importance de scanner les kits d'outils, tout comme pour n'importe quel code tiers.
En résumé, pour les équipes qui construisent leurs produits à partir de SDK tiers et qui sont soumises à des exigences de SBOM, l'analyse de composition binaire est essentielle pour assurer la conformité réglementaire. Aujourd'hui, cela s’applique aux systèmes développés pour le gouvernement fédéral américain, aux dispositifs médicaux, à l’automobile et autres infrastructures critiques, ainsi qu'au marché européen plus large.