Un an plus tard : Six domaines à surveiller dans l'évolution du SBOM

Au cours de l'an passé, il y a eu une évolution concernant les discussions sur le SBOM.

Il y a un peu plus d'un an, en réponse aux exploits de SolarWinds et Log4j, la Maison Blanche a publié le décret 14028 sur l'amélioration de la cybersécurité du pays (Executive Order 14028 on Improving the Nation's Cybersecurity). Cette ordonnance mettait particulièrement l'accent sur le mandat visant à renforcer la "sécurité de la chaîne d'approvisionnement des logiciels" et, plus précisément, sur l'introduction de "l’inventaire des logiciels" (Software Bill of Materials – SBOM).

Le TLDR (too long/didn’t read) pour les SBOM vient du fait que les logiciels commerciaux manquent souvent de transparence, et qu’ils ne mettent pas suffisamment l'accent sur la capacité du logiciel à résister aux attaques et ne disposent pas de contrôles adéquats pour empêcher les manipulations par des acteurs malveillants. Essentiellement, un SBOM est une liste complète et formellement structurée de composants, de bibliothèques et de modules utilisés par un logiciel. En théorie, il vous permettra de déterminer exactement quels logiciels commerciaux et open source tierce composent votre progiciel.

Au cours de l’an passé, il y a eu une évolution concernant les discussions sur le SBOM, alors que le gouvernement et l'industrie ont collaboré sur le sujet du problème, les théories de mise en œuvre, la structures, les spécifications et les normes. Il est à croire que les SBOM seront l'une des tendances les plus intéressantes à suivre en matière de sécurité au cours de l'année à venir. Voici quelques-unes des discussions les plus importantes sur les SBOM qui devraient être sur le radar de tous les responsables de la sécurité, alors que nous passons de la phase des définitions aux premières étapes de la mise en œuvre dans le monde réel :

Le front-end et le back-end des SBOM restent encore à définir

Les SBOM auront besoin d'une couche dorsale sécurisée pour le stockage et les intégrations. Les développeurs auront besoin d'un frontal qui intègre les vulnérabilités de sécurité dans leur flux de travail sans nuire à la productivité. Il s'agit d'une opportunité considérable pour l'écosystème des fournisseurs de cybersécurité, mais nous n'avons pas encore vu de mise en œuvre MVP sur le marché. Cela va changer en 22.

L'automatisation sera cruciale

Disposer de zettaoctets de données et de journaux que personne ne consulte est une perte de temps et d'argent. Les gouvernements fédéraux et étatiques - en vertu du décret - seront les premiers grands consommateurs de SBOM. Mais pour que les SBOM décollent, ils devront être conçus en tenant compte de l'automatisation comme une caractéristique de premier ordre. OSCAL, le langage du NIST (National Institute of Standards and Technology) pour l'automatisation de la sécurité, se marie parfaitement avec le SBOM, et pour que les SBOM décollent dans le gouvernement, ils devront être liés à l'automatisation du processus FedRAMP (programme fédéral de gestion des risques et des autorisations).

La surveillance continue, la fonction que tout le monde souhaite

Le monde compte tellement de logiciels - projets open source, cadres de langages de programmation et bibliothèques - que non seulement la plupart des organisations n'étaient pas au courant de la vulnérabilité de Log4J, mais même lorsqu'elles l'étaient, elles ne savaient pas si et où elles exécutaient Log4J. Tout le monde s'accorde à dire que la fonctionnalité ultime du SBOM sera la surveillance continue qui nous indique à tous non seulement quand quelque chose a changé qui modifie notre posture de sécurité, mais aussi si et où nous l'exécutons.

L'importance de l'uniformité des informations du SBOM

En tant qu'industrie, nous devrions chercher à rationaliser le processus du SBOM et à le traiter de manière aussi uniforme que possible. Le pire scénario est d'avoir un cadre complexe que personne ne comprend et qui est donc ignoré. Nous devrions considérer les SBOM comme une étape 0 dans la sécurité de la chaîne d'approvisionnement des logiciels. Ils sont le début du voyage sur la façon dont nous, en tant que communauté, pouvons travailler ensemble pour construire des logiciels plus sûrs.

De multiples cadres SBOM

Le NIST et l'OWASP (Open Web Application Security Project) ont des cadres différents, et les responsables de la sécurité voudront avoir le choix. Le gouvernement ne peut pas vous imposer un cadre plutôt qu'un autre, mais les entreprises devront être suffisamment agiles pour pouvoir envisager n'importe quel cadre SBOM.

Une meilleure collaboration entre les entreprises et les agences

Une chose captivante à propos du SBOM est sa capacité à accélérer la collaboration entre pairs en matière de sécurité. On constate un intérêt énorme pour le SBOM de la part de l'IT-SAC, dont la mission est d'être un multiplicateur de force dans la collaboration et le partage d'informations pertinentes et exploitables sur les cybermenaces. En théorie, si nous parvenons à mieux partager les informations sur les exploits de sécurité grâce au SBOM, nous verrons beaucoup plus de ce type de collaboration dans les espaces sécurisés.

Log4j et SolarWinds ont éveillé l'industrie aux portes latérales que représentent les artefacts logiciels non sécurisés et aux exploits rendus possibles par leur nature transitive. Les pouvoirs publics et les entreprises sont tout à fait d'accord pour dire que nous devons savoir ce que contiennent nos logiciels et où ils s'exécutent, et qu'il s'agit là de la première étape du mouvement en faveur de la sécurité de la chaîne logistique logicielle.