SBOM et cadre de développement logiciel sécurisé

Temps de lecture : 6 minutes
Curtis Yanko de CodeSecure résume son analyse

Découvrez dans cet article :

• Comment SSDF, en particulier en réponse à l’EO-14028, redéfinit les pratiques de développement de logiciels sécurisés.
• Le rôle des SBOM dans la protection de l’infrastructure logicielle, l’identification et la réponse aux vulnérabilités, et bien plus encore.

• Comprendre le SSDF

Dès le départ, le document donne le ton dans son « résumé » en soulignant que le SSDF est un « ensemble de base de pratiques de développement de logiciels sécurisés de haut niveau » tout en soulignant que peu de modèles SDLC « … abordent explicitement la sécurité des logiciels en détail. » Le respect du SSDF devrait aider les producteurs de logiciels à réduire les vulnérabilités et l'impact potentiel des exploitations tout en s'attaquant aux causes profondes des vulnérabilités. Alors que le résumé continue en expliquant comment le SSDF facilite la communication, j'ai senti que l'introduction avait une description plus succincte : « Ce document fournit un langage commun pour décrire les pratiques fondamentales de développement de logiciels sécurisés… …Le langage commun aide à faciliter les communications sur les pratiques logicielles sécurisées entre parties prenantes organisationnelles internes et externes… »

• Pratiques de haut niveau du SSDF

Alors, quelles sont exactement les pratiques de haut niveau ? Il s'avère qu'il n'y en a que 4, mais celles-ci sont ensuite divisées en « tâches » et le document fournit même des « exemples de mise en œuvre théoriques » pour aider à clarifier chaque « tâche ». Il est important de noter que le SSDF n’est pas prescriptif quant à la manière de mettre en œuvre chaque pratique : « l’accent est mis sur les résultats des pratiques plutôt que sur les outils, techniques et mécanismes permettant d’y parvenir ».

• Préparer l’organisation : une tâche générale

La première consiste à préparer l’organisation, ce qui, je pense, sera d’accord avec la plupart des gens, comme étant une tâche globale des trois pratiques restantes. La préparation de l’organisation se décompose en trois tâches simples :

• Identifiez et documentez toutes les exigences de sécurité pour l’infrastructure et les processus de développement et maintenez-les au fil du temps.
• Identifier et documenter toutes les exigences de sécurité que les logiciels développés en interne doivent respecter et maintenir au fil du temps.
• Communiquer les exigences à tous les tiers qui fourniront des composants logiciels commerciaux destinés à être réutilisés par le propre logiciel de l'organisation.

La pratique suivante consiste à protéger le logiciel (PS), qui est décrite comme « Les organisations doivent protéger tous les composants de leur logiciel contre la falsification ou l'accès non autorisé. » Lorsque nous examinons les « tâches », nous constatons que cette partie concerne des éléments tels que la prévention des modifications non autorisées du code, la fourniture d'un mécanisme pour vérifier l'intégrité du logiciel, ainsi que l'archivage et la protection de chaque version du logiciel. C’est dans ce troisième élément que nous obtenons notre première mention des SBOM. La tâche PS 3.2 nous demande de collecter, sauvegarder, maintenir et partager les données de provenance pour tous les composants de chaque version du logiciel (c'est-à-dire dans un SBOM). Il suggère également de mettre ces SBOM à la disposition des consommateurs du logiciel. Pour ceux qui cherchent spécifiquement « où » un SBOM s'intègre dans le SSDF, vous avez là votre première instance.

L’endroit suivant où nous voyons les SBOM mentionnés dans le SSDF est dans le Produce Well-Secured Software (PW) qui est initialement décrit dans les termes les plus larges. Pour le paraphraser, identifiez le risque pour le logiciel et comment la conception et l’architecture atténuent ces risques. Dans un petit commentaire à la fin de cette pratique, il y a un merci à Secure By Design en disant que « La prise en compte des exigences de sécurité et des risques lors de la conception de logiciels est essentielle pour améliorer la sécurité des logiciels et contribue à améliorer l'efficacité du développement. C’est dans PW 4 que nous voyons réapparaître les SBOM, ce qui correspond à la pratique consistant à « réutiliser les logiciels existants et bien sécurisés lorsque cela est possible au lieu de dupliquer les fonctionnalités ». La tâche PW 4.1 développe essentiellement cela avec : « Acquérir et maintenir des composants logiciels bien sécurisés auprès de développeurs commerciaux, open source et autres tiers pour une utilisation par les logiciels de l'organisation. L'exemple de mise en œuvre nationale n° 3 nous indique d'obtenir un SBOM pour tous les logiciels afin d'aider aux évaluations des risques. Voilà la deuxième instance spécifique des SBOM dans le SSDF. Fait intéressant, ils sont essentiellement symétriques dans la mesure où PS dit de créer et de partager des SBOM et PW nous demande d'obtenir des SBOM pour des logiciels tiers.

La dernière pratique est la réponse aux vulnérabilités (RV) qui ne mentionne les SBOM dans aucune de ses tâches ou exemples de mise en œuvre théorique. L'objectif de RV 1.1 est de « recueillir des informations auprès des acquéreurs de logiciels, des utilisateurs et des sources publiques sur les vulnérabilités potentielles du logiciel et des composants tiers que le logiciel utilise et d'enquêter sur tous les rapports crédibles ». Le troisième exemple de mise en œuvre suggère de « examiner automatiquement les données de provenance et de composition logicielle de tous les composants logiciels afin d'identifier toute nouvelle vulnérabilité dont ils disposent ». Cela ressemble énormément à une surveillance continue des nouvelles vulnérabilités jusqu'au niveau des sous-composants, ce qui est facilement réalisé avec les SBOM dans une plate-forme capable de vérifier régulièrement toutes les vulnérabilités signalées.

En résumé, il semble que les SBOM jouent un rôle dans toutes les facettes du SSDF, depuis l'identification des besoins à un niveau élevé jusqu'à l'application pratique des SBOM pour protéger votre infrastructure, les logiciels que vous produisez, et ils jouent un rôle dans la surveillance continue et la réponse aux vulnérabilités. . La section Réponse aux vulnérabilités comprend le signalement de vos propres vulnérabilités et, par extension, celles qui n'affectent pas votre logiciel, ainsi que la surveillance des vulnérabilités dans les logiciels tiers. Le SSDF n'est pas radicalement différent des autres cadres de développement de logiciels sécurisés et je pense que vous constaterez que les SBOM jouent également un rôle important dans toutes les fonctions de ceux-ci. La feuille de calcul mappe facilement sa « tâche » à d’autres cadres de sécurité dans la colonne des références. Ceux-ci répertorient le cadre et la pièce spécifique à laquelle il se rapporte. Par exemple, notre PS 3.2 ci-dessus correspond à BSIMM : SE3.6, EO14028 : 4e(vi), 4e(vii), 4e(ix), 4e(x) et à d'autres normes NIST comme SP80053 : SA-8, SR- 3, SR-4 ou SP800161 : SA-8, SR-3, SR-4.

Supposons donc que quelqu'un vous demande exactement comment les SBOM s'intègrent. Dans ce cas, vous comprenez maintenant qu'ils nous aident à sécuriser et à surveiller les logiciels que nous produisons, à identifier et à gérer les risques liés aux logiciels que nous acquérons. Ils nous aident à identifier et à répondre aux vulnérabilités émergentes.